What is the Credantic client portal?
It is the system we use to run projects with clients. Clients sign in to see their projects and milestones, review documents that need their approval, view invoices and raise support requests. Our staff use a separate set of screens to manage the same information. We built it for ourselves, so this is an internal project and not a description of client work.
- Projects and milestones: what has been agreed and what is done.
- Documents to approve: items that are waiting for the client's review.
- Invoices: what has been billed, in one place.
- Support requests: a single place to ask for help, instead of a long email thread.
Why did we build our own portal?
Projects go better when both sides can see the same facts: what has been agreed, what is done, what is waiting for a decision and what has been invoiced. A shared portal puts milestones, documents and invoices in one place, so questions are answered by looking and not by searching old email.
How is it built?
The portal is an ASP.NET Core application using Blazor for the interface and PostgreSQL for data. We chose mainstream technology on purpose: it is well documented, it will be supported for a long time, and another developer can pick it up. It is the same stack we offer for custom software development and web development.
How does it keep one client's data apart from another's?
This is called tenant isolation, and it is the most important property of any portal that holds more than one client. We use two layers. First, every query is filtered by the client's organization, so a record from another organization is never returned. Second, an authorization handler checks the access again before the record is shown. The second layer exists because a mistake in one place should not be enough to expose data.
Automated tests then check that a user in one organization cannot read another organization's data. In ASP.NET Core, handlers like this evaluate access requirements for each request, as described in Microsoft's documentation on policy-based authorization.
How is sign-in protected?
- Two-factor sign-in is required for staff.
- The secrets behind authenticator codes are encrypted at rest.
- Sign-in attempts are rate limited, which slows down password guessing.
How are uploaded files handled?
Documents are uploaded by both sides, and uploads are a classic route for attacks. Files are checked by extension, by content and by size before they are accepted, and they are stored outside the web root, so the web server cannot serve them as if they were part of the site. This follows the main points of the OWASP File Upload Cheat Sheet.
What gets recorded?
The portal keeps an audit log of actions, so that when something changes, there is a record of who changed it and when. An audit log does not prevent mistakes, but it makes them findable and fixable.
What happens to website enquiries?
When someone fills in a form on the Credantic website, the enquiry is saved to the portal database before any email is sent. If the mail system is down, the enquiry is not lost, because it is already stored and can be sent again.
Why these controls?
They follow the worst things that could go wrong with a portal that holds several clients' information. The first is one client seeing another client's data, so isolation is checked in two places and tested. The second is a compromised staff account, because staff can reach more than any single client can, so staff sign-in needs a second factor. The third is hostile or oversized files arriving through upload. The fourth is not being able to explain a change afterward, which is what the audit log is for. None of these is unusual. They are the basics, applied consistently.
Which control protects against which risk?
| Control | Risk it addresses | How it works here |
|---|---|---|
| Tenant isolation | One client seeing another client's data | Queries filtered by organization, checked again by an authorization handler, with automated tests |
| Staff two-factor sign-in | A stolen or guessed staff password | Required for staff, with authenticator secrets encrypted at rest |
| Sign-in rate limiting | Password guessing at speed | Repeated attempts are slowed |
| Upload checks | Harmful or oversized files | Checked by extension, content and size, and stored outside the web root |
| Audit log | Changes nobody can explain | Actions are recorded |
| Save before send | Lost enquiries during a mail outage | Enquiries are stored in the database before they are emailed |
What are the limits of this description?
This write-up describes design choices. It is not a security audit, a certification or a guarantee, and no system is without risk. It also leaves out infrastructure details on purpose. What it shows is how we approach the problem when we build for our own clients' information.
What does this mean for your project?
If you need a portal, an internal tool or a multi-tenant product, the same questions apply: how is each customer's data kept apart, how is sign-in protected, how are uploads handled and what is recorded. Ask any developer for their answers, and ask for tests that prove them. Read more about our custom software development, our web development work, and how we approach SaaS development.