The Entrypage system is designed to do three things:

  • Create and manage accounts
  • Connect with other domains, and use Entrypage as a gate
  • Apply policies to users so that they can access only what they are entitled to see.

To make that possible, the Entrypage system works with the following core concepts:

  • Domain: An isolated realm where accounts and policies are defined and managed.
    • Sandbox domains: We strongly believe in the DTAP (Development, Testing, Acceptance, Production) methodology. Entrypage is designed to support sandbox domains, allowing development teams to thoroughly test changes before they go to production. These domains are recognizable as they end with *.sandbox.entrypage.io.
    • Production domains: For production environments, development teams must use their own DNS aliases. Using production domains is a feature reserved for paid accounts.
  • Clients: Apps that require authentication and/or authorization.
  • Users: Individuals who interact with systems. They can be:
    • Local users: Accounts created directly within the Entrypage system’s own database. These users authenticate with passkeys, magic-links, or other passwordless authentication methods.
    • Federated users: Accounts managed by an external Identity Provider. The Entrypage system doesn’t manage their credentials; it just trusts the external provider.
  • Claim Mapping: The process of translating information (claims) from an external Identity Provider into a format that the Entrypage system can understand and use to apply Policies. This ensures a user’s permissions are correct, even if their account is managed elsewhere.
  • Policies: Rules that determine what clients a user may or may not access.
  • Identity Providers: A service that creates, maintains, and manages user identity information. This can be the Entrypage system itself or an external service like Google or Azure AD.

What Entrypage does:

Entrypage is a serverless Single Sign-On (SSO) solution. It provides people access to protected resources using protocols like OAuth and OpenID Connect. A simplified view of the process of authentication and authorization with Entrypage is depicted in the diagram:

flowchart TD
    A[User attempts to sign in] --> B{Sign-in method}
    
    B -->|"External login (e.g. social or enterprise)" | C["Delegate Authentication to External Identity Provider"]
    B -->|"Passkey login"| D["Local login via passkeys (Entrypage)"]

    D --> H

    C --> F["Translate claims (e.g. roles, groups, entitlements)"]
    F --> G["Check applicable access policies"]
    G --> H{Access granted?}
    H -->|Yes| J["Allow access to client"]
    H -->|No| K["Deny access"]

When a user attempts to sign in, the system prompts their sign-in method. If they authenticate using an external login (like a social media or enterprise account), the authentication process is delegated to that external Identity Provider. The system then translates the claims (like roles or groups) from that provider and checks the applicable Policies to see if access should be granted.

Alternatively, if the user uses a Passkey, the system handles the local login directly. Regardless of the sign-in method, the system checks the access policies. If the user meets the policy requirements, they are granted access to the requested Client. If not, their access is denied.