Older applications, over protocols they already speak.
An older application that cannot use today's usual sign-in standard, OIDC, can still sit behind Pramaan, over a protocol it already speaks. Pramaan can sign people in through a directory to bind to (LDAP), a sign-in check in front of the application, or SAML. A direct connection admits a client while the application keeps its own login. Each of these stays off until you switch it on.
Which way fits which application
- LDAP
- Sign-in check
- SAML
- Direct
| Protocol | For |
|---|---|
| LDAP provider | Applications that look people up in a directory: applications bind and search; writes are refused. |
| Sign-in check | Web applications that have no sign-in of their own, behind a web server that can ask before it forwards a request. |
| SAML 2.0 identity provider | Applications that speak SAML, for sign-on started by the application. |
| Direct connection | Clients with a protocol of their own, such as SSH, RDP and Postgres, from the Pramaan desktop app. |
LDAP: a directory to bind to
An application that only speaks LDAP binds to Pramaan's LDAP provider and looks up people and groups. The provider is read-only: applications bind and search; writes are refused. It runs on a network address of its own.
A sign-in check in front of the application
For web applications that have no sign-in of their own, the web server in front of them asks the broker before it passes a request on. The broker decides with your access rules and answers with the person's identity in headers for the application, or refuses. The check stays off until set up: it is on once an administrator sets a cookie domain for it and the identity store is on.
SAML: Pramaan as the identity provider
As a SAML identity provider, Pramaan signs people in to SAML 2.0 applications, for sign-on started by the application; it answers once you give it a signing key and certificate. See identity for the other direction.
Direct connections, for clients with their own protocol
A client that speaks its own protocol reaches the application over a direct connection, through the application's connector. Each connection is checked on its own: the access token, the person's groups and your access rules. Forwarding runs in the Pramaan desktop app only: the Android app lists direct-connection apps and does not forward them; the recipe is on the private-app access page.
What Pramaan does not speak
For your engineers
Technical detail: the proxies and the direct path
The sign-in check is forward-auth: a reverse proxy such as nginx auth_request or Traefik forward-auth asks the broker about each request. A direct connection is raw TCP, through the broker's raw-TCP listener.
Questions
Can a legacy application change data over LDAP?
No. The LDAP provider is read-only: applications bind and search; writes are refused.
Does an LDAP sign-in ask for MFA?
No. With LDAP, a bind checks a password, against the stored password or the upstream directory, with no MFA.
Which web servers can run the sign-in check?
One that can ask the broker before it forwards a request, such as those the technical detail above names. Also, the application must be a host under the parent domain that the sign-in cookie is set for.
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 people forward direct connections from their phones?
No. Forwarding runs in the Pramaan desktop app only: the Android app lists direct-connection apps and does not forward them.
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.