ActivID AS IDP Solution

The ActivID AS IDP solution offers an authentication portal with SAMLv2 or OpenID Connect protocol endpoints that can be used to verify the identity of end users for service providers or relying parties.

ActivID OpenID Connect Endpoints

The following table provides an overview the ActivID Authentication Server OAuth/OpenID Connect API endpoints.

Endpoint	Description
Authorization	For receiving OpenID Connect authentication requests from client applications.
Token	For exchanging authorization codes, Refresh tokens, resource owner passwords and client credentials for an access, refresh and/or ID token.
UserInfo	Protected resource for releasing consented claims (name, contact and other details) about the subject (end user).
Token revocation	Standard endpoint for client applications to revoke issued access and Refresh tokens.
Client registration	Standard endpoint to dynamically register an OpenID client.
Token introspection	Standard endpoint to get a token’s state and information.

ActivID SAML Support

The ActivID AS supports the following SAML Profiles, Protocols, and Protocol Bindings.

Profile	Message Flows	Binding	Supported
Web SSO	<AuthnRequest> from SP to IDP	HTTP redirect	Yes
		HTTP POST	Yes
		HTTP artifact	Yes
	IDP <Response> to SP HTTP POST	HTTP POST	Yes
	IDP <Response> to SP HTTP POST	HTTP artifact	No
Enhanced Client/Proxy SSO			No
Identity Provider Discovery			No
Single Logout			No
Name Identifier Management	<ManageNameIDRequest>	HTTP redirect	Yes
		HTTP POST	Yes
		HTTP artifact	Yes
		SOAP	Yes
	<ManageNameIDResponse>	HTTP redirect	Yes
	<ManageNameIDResponse>	SOAP	No
Artifact Resolution	<ArtifactResolve>,<ArtifactResponse>	SOAP	No
Authentication Query	<AuthNQuery>, <Response>	SOAP	No
Attribute Query	<AttributeQuery>, <Response>	SOAP	No
Authorization Decision Query	<AuthZdecisionQuery>, <Response>	SOAP	No
Request for Assertion by Identifier	<AssertionIDRequest>,<Response>	SOAP	No
Name Identifier Mapping	<NameIDMappingRequest>, <NameIDMappingResponse>	SOAP	No
AML URI binding	GET, HTTP Response	HTTP	No

Web SSO Profile Use Case using SAML

A user attempts to access a protected resource hosted by an SP.
The SP generates a SAML authentication request. The SAML request is encoded and embedded into the URL for the ActivID IDP.
The SP sends a redirect to the user’s browser.

The redirect URL includes the encoded SAML authentication request that will be submitted to ActivID IDP. The user is redirected to the ActivID Authentication Portal.

In addition to HTTP-redirect, additional bindings are also supported by ActivID IDP. For information on bindings supported by ActivID IDP, see ActivID SAML Support .

The ActivID IDP decodes the SAML request and extracts the authentication context.
The ActivID Authentication Portal authenticates the user by requesting his valid login credentials.

Depending on the content of the SP Authentication Request, the mappings defined for the SAML Authentication Classes authentication, the ActivID Authentication Portal displays the appropriate user login page.

Note: The SP can request a specific authentication policy to be used by specifying an authentication class within the SAML Authentication Request.

The ActivID IDP authenticates the user and creates an SSO session.

If the SP asks for an assertion subject of the form of a federated identity a Federated ID attribute (user alias) is then created to identify the SP user and stored in the ActivID AS database. Once redirected to the SP, the user is prompted to enter SP credentials to associate this federated identity with the local account. The user is then granted access to the resource. The ActivID AS and SP user accounts are now linked and subsequent logins will no longer require this step.

ActivID IDP generates a SAML response that contains the authenticated user’s subject name. In accordance with the SAML 2.0 specification, this response is digitally signed with the ActivID IDP signature certificate.
ActivID IDP encodes the SAML response and returns that information to the user’s browser.
ActivID IDP includes JavaScript on the page that enables the browser to automatically submit the form to the SP’s Assertion Consumer Service (ACS) URL.
The SP verifies the SAML response using the ActivID IDP’s public key. If the response is verified, then the SP redirects the user to the destination URL.
The user has been redirected to the destination URL and is logged on to the protected resource.

For details on how to configure the ActivID IDP, see Configure the ActivID Identity Provider.

Introduction to SAMLv2

The Security Assertion Markup Language (SAML) v2 open standard enables Service Providers to delegate the authentication process of their end users to a trusted third party called the identity provider. SAML 2.0 is a version of the SAML OASIS standard for exchanging authentication and authorization data between security domains.

A Service Provider can be an online banking website, a cloud-based enterprise solution, an internal enterprise Web application, or a VPN gateway. Using this model, multiple Service Providers can rely on a single identity provider to federate (centralize) authentication, authorization, and auditing services.

ActivID AS acts as an Identity Provider (IDP) that provides federated, strong, versatile authentication to end users accessing any type of SAMLv2-compliant Service Provider.

Identity Provider (IDP) – a role owned by a system entity that creates, maintains, and manages identity information for principals and provides principal authentication to other Service Providers within a federation, such as occurs with Web browser profiles. ActivID AS acts as an IDP.
Service Provider (SP) – a role owned by a system entity providing services to users or system entities.

When a user authenticates to a Service Provider, the user is redirected to the ActivID Authentication Portal, which then authenticates the user. When the user is successfully authenticated, ActivID AS (the identity provider) provides a SAML assertion to the Service Provider.

SAML includes a set of specifications describing security assertions that are encoded in XML, profiles for attaching the assertions to various protocols and frameworks, the request/response protocol used to obtain the assertions, and bindings of this protocol to various transfer protocols (for example, SOAP and HTTP).

ActivID AS leverages SAML v2 to enhance its capacity to authenticate and authorize users. For detailed information on SAML concepts, refer to OASIS SAML V2.0 technical documentation available at http://www.oasis-open.org/standards#samlv2.0.

SAML Assertion

SAML associates a user with identity information that can be used to determine the user's access rights within a specific domain. SAML defines three kinds of assertions declaring one or more facts about a subject:

Authentication assertions – state that the user has proven identity by a specific method at a specific time.
Attribute assertions – contain specific details about the user, such as an employee number or an account number.
Authorization assertions – state the resources a user can access and under what conditions they can be accessed.

Assertions are coded statements generated about events that have already occurred.

Note: SAML only makes assertions about credentials. It does not actually authenticate or authorize users. SAML assertions must be signed by the IDP (the role ActivID AS plays), and can be encrypted based on the Service Provider metadata.

SAML assertions contain some or all of the following information:

Issuing information – who issued the assertion, when it is issued, and the assertion identifier.
Subject information – the name of the subject, the security domain, and other optional subject information, for example, the public key. The subject name ID must be configured and mapped to an ActivID AS user attribute, including the Userid.

SAML Authentication Context

SAML assertions assert to the Service Provider that the user did indeed authenticate with the IDP (ActivID Authentication Portal) at a specific time using a specific authentication method. Other information about the authenticated user can be disclosed in an authentication assertion. This is referred to as the authentication context (that is, the information added to the SAML assertion).

For example, a user uses a simple identifier and a self-chosen password to authenticate to a Service Provider. The IDP sends an assertion to a second Service Provider that states how the user was authenticated to the first Service Provider. By including the authentication context, the second Service Provider can place an appropriate level of assurance on the associated assertion. If the SP’s are banks, they will require stronger authentication than what has been used and respond to the IDP with a request to authenticate the user again using a more stringent context.

To enable interoperability with SP’s, you must create specific authentication policies mappings in ActivID Authentication Portal to link to SAML authentication context classes.

SAML Basic Workflow

This illustration describes the primary SAML workflow of the Web Browser SSO Profile. For information on other major profiles and federation use cases, refer to the SAML technical documentation available at http://www.oasis-open.org/standards#samlv2.0.

In the following list of steps, the IDP is the ActivID Authentication Portal.

A user wants to access a protected resource in the federated network.
The Service Provider for that resource directs the user to the IDP for authentication. The IDP provides a SAML Web SSO assertion for the user's federated identity back to the Service Provider.
The SSO Service determines whether the user has an existing logon security context at the IDP that meets the default or requested authentication policy requirements. If not, the IDP interacts with the browser to challenge the user to provide valid credentials.
The user logs on with valid credentials.
The IDP SSO Service builds a SAML assertion representing the user's logon security context. Since a POST binding is going to be used, the assertion is digitally signed and then placed within a SAML <Response> message.
The browser issues an HTTP POST request to send the form to the Service Provider's Assertion Consumer Service.
An access check is made to establish whether the user has the correct authorization to access the resource. If the access check passes, the resource is then returned to the browser.

SAML Benefits

The ActivID Authentication Portal acts as an Identity Provider providing federated, strong, versatile authentication to end users accessing any type of SAMLv2-compliant Service Provider.

Interoperability – enables SP’s to securely exchange information about users, Web services, and authorization information without requiring partners to change their current security solutions.
Open Solution – works with multiple, industry-standard transport protocols such as HTTP, SMTP, FTP, as well as multiple XML document exchange frameworks such as SOAP.
Single Sign-On – enables Web users to navigate sites with their entitlements so that companies and partners in a trusted relationship can deliver single sign-on services across Web sites, as well as secure access to shared resources.
Federated Identity – establishes a federated identity that is a shared name identifier used to refer to an end user or an entity that is using the services offered by various partners.

Identity Federation

The ultimate goal of identity federation is to enable users of one domain to securely access data or systems of another domain seamlessly – and without the need for redundant user administration.

Identity federation occurs when a user chooses to unite distinct Service Provider and ActivID Authentication Portal accounts, while retaining the individual account information with each provider. The user establishes a link that allows the exchange of authentication information between provider accounts. Users can choose to federate any or all identities they have. After identity federation, when a user successfully authenticates to one of the Service Providers, access to any of the federated accounts within the circle of trust is allowed without having to re-authenticate.

Identity federation supports cross-domain single sign-on and interchanges access control information with a wide range of partners, reflecting business trust relationships. The SAML protocol is interoperable. Since cloud Service Providers implement different identity federation protocols or different versions of the same protocol, the enterprise cloud can leverage Security Token Service to interoperate between these different SSO practices.

With SAML, the remote access solution improves the user's experience in securely accessing content between enterprise and cloud environments. SAML simplifies identity and access management and also provides interoperable identity and access management functionality in hybrid cloud environments.

The benefits of identity federation come in many folds:

Reduce cost by eliminating the need to use proprietary solutions.
Increase security and lower risk by enabling an organization to identify and authenticate a user once, and then use that identity information across multiple systems, including external partner websites.
Improve privacy by enabling the user to control what information is shared, or by limiting the amount of information shared.
Improve the end-user experience by eliminating the need to redundantly login through cross-domain SSO.