One sign-in for the applications you connect.
Your people sign in once, and the applications you connect accept that sign-in. Pramaan's server, the broker, is the identity provider: the service your applications ask who a person is. It speaks OIDC, SAML 2.0, LDAP, SCIM, each for its own job. Each one beyond OIDC that opens a new way in stays off until you switch it on.
Which protocol does what
| Protocol | What it does |
|---|---|
| OIDC | Applications sign people in and receive tokens: OIDC, with a safeguard against reused sign-in codes required for public clients. |
| SAML 2.0 identity provider | Pramaan signs people in to applications that speak SAML, for sign-on started by the application; it answers once you give it a signing key and certificate. |
| SAML service provider | People sign in to Pramaan through another organisation's SAML identity provider. Off until an administrator turns it on. |
| SCIM 2.0 outbound | Pramaan pushes its users into a downstream application. |
| SCIM 2.0 inbound | An external identity provider pushes users and groups into Pramaan. Off until an administrator turns it on. |
| LDAP provider | Legacy applications bind to Pramaan as a directory: applications bind and search; writes are refused. Off until an administrator turns it on. |
SAML in both directions
As a SAML identity provider, Pramaan asserts who the person is to an application; it answers once you give it a signing key and certificate. As a SAML service provider, it accepts a person whom another organisation's identity provider has signed in. Each direction has its own switch.
Provisioning with SCIM
Outbound, Pramaan pushes its users into a downstream application that hosts a SCIM 2.0 service. Inbound, an identity provider such as Entra ID or Okta pushes users and groups into Pramaan; inbound SCIM is switched on separately, and with it off the routes do not exist. Both directions can run at once.
An LDAP directory for legacy applications
An application that only speaks LDAP can bind to Pramaan's LDAP provider and look up people and groups. The provider is read-only: applications bind and search; writes are refused. It starts only when you give it a network address of its own.
What Pramaan does not speak
Questions
Can Pramaan replace a RADIUS server?
No. Pramaan has no RADIUS server, so equipment that authenticates people over RADIUS needs a RADIUS server of its own.
Can Entra ID or Okta provision users into Pramaan?
Inbound SCIM is built for that: once inbound SCIM is switched on, an identity provider pushes users and groups to Pramaan. Inbound SCIM has not yet been run against a live Entra ID or Okta tenant, and inbound SCIM has no request that deletes a user or group.
Can a legacy application change data over LDAP?
No. The LDAP provider is read-only: applications bind and search; writes are refused.
Can people sign in through another organisation's identity provider?
Over SAML, yes, once Pramaan's service provider is switched on. As a service provider, sign-on started at the identity provider and encrypted assertions are not supported, and the request it sends is not signed.
Is a phone or browser app's sign-in code protected?
Yes: Pramaan speaks OIDC, with a safeguard against reused sign-in codes required for public clients.
Talk to us, or try it first
-
Book a walkthrough
Against your own apps, not slides.
-
Run the lab
It uses a demonstration account; none of your data is involved.
-
See pricing
Published floors, named-user bands and what every tier includes.