Overview

Ceptor supports Identity Federation with third parties using SAML or OpenID Connect, or by supplying various proprietary methods via custom Authentication plugins, such as ETicket.

These federations have existed for many years, configured via name/value pairs in the session controllers configuration.
See Microsoft ADFS Integration / WebSSO SAML and JWT / OpenID Connect for details.

But as a new feature in Ceptor v6.4, these can be configured in an easily accessible GUI within Ceptor Console instead of the older method, making it easier to configure.
Configuration is now stored as JSON objects within the configuration, but for backwards compatibility reasons, the older approach using properties documented in the links above is still possible.

Note that if the session controller configuration contains a JSON object called federation_JSON_ then this JSON type configuration is used, and the older properties are ignored.

OAuth2 / JWT / OpenID Connect

Concepts

In its OpenID Connect related configuration, Ceptor has these elements.

• Tokens
• Scopes
• Fields
• Identity Providers

Tokens

Tokens are distinct and separate configurations for JWT Tokens - it covers configuration for how to issue tokens, but also how to parse tokens received from others.
This approach makes it possible to issue different tokens with separate content to different parties.

When used together with Ceptor API Management it is possible to specify specific types of tokens issued to specific Partners and Applications (see Managing Partners, Applications and Developers)

Scopes

Scopes are used to define which fields end up in which token - here you can specify that if a client asks for e.g. a scope called "salary" when requesting a token, then you control which attributes are added to the ID token, Access Token and Userinfo respectively.
This gives you fine grained control of which data you expose under which conditions.

Fields

Some attributes are themselves objects, such as the OpenID Connect "address" object - by configuring them here, you control which attributes are included, and from where the information within originates.

Identity Providers

When Ceptor authenticates users using foreign OpenID Connect Providers, you can define the authentication providers here.
These Identity Providers are then used within the Ceptor Gateway - see Location - Authentication for information about how to configure the gateway to use these identity providers under specific conditions. 

Ceptor has custom support for some identity providers which almost are following the OpenID Connect standard, such as LinkedIn and Facebook.

SAML / WebSSO

Concepts

Ceptor can be configured to use SAML / WebSSO (Web Single SignOn) to federate identity to or from 3rd parties.

Using SAML2, SAML1.1 and WS-Trust it is possible to share identities with other Service Providers or Relying Parties as they are also called, or you can use other Identity Providers to authenticate users in Ceptor.

SAML Service Provider / Relying Party

A SAML Service Provider is a site that receives identities from Ceptor - meaning it uses Ceptor as an Identity Provider for authenticating users.

For each SAML Service Provider we issue SAML tokens to, we have complete control over which attributes we wish to send to it.
Most of the attributes can just be configured, e.g. userid, name and groups, but writing scripts to completely tailor the SAML ticket to any purpose is also supported - using these scripts it is possible to change all parts of the issued SAML login response ticket.

SAML Identity Provider

Ceptor can be configured to authenticate an end-user by redirecting him to a 3rd party site which issues SAML tickets that Ceptor then parses and validates and uses to authenticate the users, thereby trusting the 3rd party to do the authentication.

For each SAML IdentityProvider we trust, a corresponding configuration of this identity provider along with its SAML metadata or trustedcertificates is needed.

Federation and Ceptor Gateway

The Federation modules in Ceptor Session Controller contains the mechanisms for validating and issuing SAML / JWT tokens, but they need to be called from somewhere else with either a ticket issued by someone, or in order to issue tickets themselves.

Using Ceptor Agent it is possible to integrate this into any application, but you can simply configure Ceptor Gateway to do the steps needed instead.

This is done by configuring Authentication Plugins - see Location - Authentication - these authentication plugins in the gateway do the heavy lifting by receiving requests from end-user and doing the redirection back and forth between sites to obtain the tickets or send the issued tickets as needed.

For OpenID Connect, see Location - Authentication - OpenID Connect
For SAML, see: Location - SAML/ADFS/WebSSO