Authentication & Access
Conncentric delegates authentication to your organization's identity provider. It stores no passwords, maintains no local accounts, and offers no Portal login form of its own. Every human who reaches the Portal is authenticated by your identity provider first and handed to Conncentric with a token.
This page covers how that delegation works, where the user lifecycle happens, and the current state of authorization on the platform.
The delegation model
The Portal speaks OIDC (OpenID Connect) with the identity provider configured for the environment. When a user visits the Portal, they are redirected to the identity provider's login page; on success, the identity provider issues a token and returns the user to Conncentric.
| Responsibility | Lives in |
|---|---|
| Storing user credentials (passwords, MFA factors, recovery contacts) | Your identity provider. |
| Authenticating the user at login | Your identity provider. |
| Issuing session tokens | Your identity provider. |
| Accepting a valid token and rendering the Portal | Conncentric. |
| Blocking unassigned or revoked users | Your identity provider (no token is issued, so Conncentric never sees the attempt). |
The practical consequence: anything that looks like "reset my password" or "disable this account" is an operation in your identity provider, not in the Portal. The Portal has no control over it.
Conncentric stores no passwords, ships with no built-in administrator accounts, and has no local login screen. There is nothing inside the Portal to reset, unlock, or recover. Every identity operation happens in your identity provider.
Supported identity providers
Conncentric authenticates against a standards-compliant OIDC provider. We validate against Microsoft Entra ID and AWS Cognito. Because OIDC is a standard, other compliant providers, including those below, are expected to work but are not validated; contact us if you need one confirmed for your deployment.
| Identity provider | Status |
|---|---|
| Microsoft Entra ID (formerly Azure Active Directory) | Validated. |
| AWS Cognito | Validated. |
| Okta | OIDC-compliant; not validated. |
| Auth0 | OIDC-compliant; not validated. |
| Google Workspace | OIDC-compliant; not validated. |
See Authentication Configuration for installation-time configuration and provider-specific setup instructions.
LDAP-based authentication has not been validated. If your organization uses LDAP exclusively, contact your Connamara representative to discuss options.
User lifecycle
Every operation that changes who can reach the Portal runs inside your identity provider. Conncentric reacts to the outcome on the user's next login.
| Operation | Where it happens | Effect on the Portal |
|---|---|---|
| Onboard a new user | Assign the user to the Conncentric application in your identity provider. | The user can log in on their next visit. |
| Offboard a user | Remove the user from the Conncentric application in your identity provider, or disable the account entirely. | Any future login is blocked at the identity provider; Conncentric never sees the attempt. |
| Reset a password | In your identity provider's account management interface. | No change in Conncentric. The next login uses the new password. |
| Update group membership | In your identity provider. | Takes effect on the next token issued to that user. |
Three operations do not exist inside the Portal, because the controls are not there: creating a new account, resetting a password, and changing another user's credentials. Route every such request to whoever administers your identity provider.
Authorization
Role-based access control is on the roadmap but not yet implemented. Every user authenticated by your identity provider currently has full access to the Portal.
When roles ship, they are expected to build on your identity provider's existing group and claim model rather than a separate set of accounts inside Conncentric.
Using the identity provider as the authorization boundary
Until RBAC ships, Portal access is all-or-nothing once a user is assigned the Conncentric application in your identity provider. Use the identity provider itself as the authorization boundary:
| Control | How to apply it |
|---|---|
| Who can reach the Portal at all | Assign the Conncentric application in the identity provider only to the users and groups that should have access. A user not assigned cannot obtain a token. |
| Who is in scope by team or role | Gate the Conncentric application on an application group (for example, a "Conncentric Operators" group) in the identity provider. Group membership becomes the single source of truth for access. |
| Revoking a departed user | Remove the user from the application or the gating group in the identity provider. The next login attempt is blocked before it reaches Conncentric. |
This approach gives you one switch to grant or revoke Portal access. It does not give you per-feature permissions inside the Portal; that distinction arrives with RBAC.
Troubleshooting access
| Symptom | Likely cause | Action |
|---|---|---|
| User reaches the identity provider login page but is rejected there | The account is disabled, locked, or not assigned to the Conncentric application. | Resolve in the identity provider. Conncentric has no control over this state. |
| User authenticates at the identity provider but lands on an error in the Portal | The token was issued but did not meet Conncentric's acceptance criteria (issuer, audience, or claims mismatch). | Verify the identity provider configuration against Authentication Configuration. |
| User can log in but expects different permissions than what they see | All authenticated users currently have full access; role restrictions are not yet implemented. | Expected behavior until RBAC ships. Control who can log in at all by managing application assignment in the identity provider. |
See also
- Authentication Configuration: installation-time configuration and provider-specific setup.
- Plugins: which plugins and components are installed on the platform.