The integrated Identity Federation server supports the transport and receipt of request and response messages using either the Security Access Markup Language (SAML) 2.0 specifications, SAML 1.1, OpenID 2.0 or WS-Federation 1.1.
This section describes the following topics:
Note:
The specification describing how SAML might be used in a given context is referred to as a SAML profile. The specification describing how a SAML assertion and/or message is conveyed in, or transported over, another protocol is referred to as a SAML Binding.
SAML uses an eXtensible Markup Language (XML) framework to define a simple request-response protocol in order to achieve interoperability between vendor platforms that provide SAML assertions.
A SAML requester sends a SAML Request element to a responder. Similarly, a SAML responder returns a SAML Response element to the requester. Within the SAML 2.0 protocol, Identity Federation supports the functionality described in the following sections.
SSO and Federation relies on SAML artifacts and assertions to relay authentication information.
The following bindings are supported for the exchange of data regarding SSO and federation.
The HTTP Artifact Binding uses the Artifact Resolution Protocol and the SAML SOAP Binding (over HTTP) to resolve a SAML message by reference. The IdP will store the Assertion in its repository and redirect the user to the SP with a string (artifact) that references the stored Assertion. The SP will retrieve the Assertion by connecting to the IdP directly over SOAP/HTTP and presenting the artifact
The HTTP POST Binding relies on an HTML form to communicate authentication information between providers. For example, the service provider may use HTTP Redirect to send a request while the identity provider uses HTTP POST to transmit the response. The IdP can also redirect the user to the SP in an HTML FORM that contains the Assertion itself.
The Reverse SOAP binding (PAOS) is only supported when Access Manager is configured as an IdP. In this flow, the client sends a SOAP request containing a SAML 2.0 Authn Request message to the IdP. The IdP authenticates the user locally, and returns a SOAP response containing a SAML 2.0 Assertion. The client then presents the results to the remote SP.
Single Logout defines how providers notify each other of logout events. This message exchange terminates all sessions when a logout occurs at the SP or IdP.
The following profiles are supported for exchanging data regarding single logout.
The HTTP Redirect profile relies on HTTP redirects between providers. For example, the IdP redirects the user to the SP using a 302 redirect operation with the URL containing the Logout Request/Response message. This profile can be used for sending and receiving data regarding single logout.
The HTTP POST profile occurs when the IdP redirects the user to the SP using an HTML FORM containing the Logout Request/Response message. This profile can be used for sending and receiving data regarding single logout.
The SOAP Binding Profile allows the IdP to connect directly with the SP and send a Logout Request message. During logout, the IdP redirects the user to the various SPs in a sequential manner. The SP will respond with a Logout Response message. This profile relies on asynchronous SOAP over HTTP messaging calls between providers and can be used only for sending data regarding single logout.
The Name Identifier Mapping defines how an SP can obtain name identifiers assigned to a principal that has authenticated in the name space of a different SP.
When a principal authenticated to one SP requests access to a second site, the second SP can use this protocol to obtain the name identifier and communicate with the first SP about the principal - even though no federation for the principal exists between them. The SAML 2.0 NameID formats listed in Table 37-1 are supported in both IdP and SP mode.
Table 37-1 Supported SAML 2.0 NameID Formats
| NameID Format | Description |
|---|---|
|
urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified |
SP/IdP will use the applicable user attribute to populate/process the NameID value |
|
urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress |
SP/IdP will use the applicable user attribute to populate/process the NameID value |
|
urn:oasis:names:tc:SAML:1.1:nameid-format:X509SubjectName |
SP/IdP will use the applicable user attribute to populate/process the NameID value |
|
urn:oasis:names:tc:SAML:1.1:nameid-format:WindowsDomainQualifiedName |
SP/IdP will use the applicable user attribute to populate/process the NameID value |
|
urn:oasis:names:tc:SAML:2.0:nameid-format:kerberos |
SP/IdP will use the applicable user attribute to populate/process the NameID value |
|
urn:oasis:names:tc:SAML:2.0:nameid-format:persistent |
SP/IdP will use either:
|
|
urn:oasis:names:tc:SAML:2.0:nameid-format:transient |
IdP will generate a random value |
|
custom value |
When this NameID format is used, OIF/IdP will use a user attribute to populate the NameID value |
Regarding the security of identity data transported using the SAML 2.0 specifications,the following is true.
All outgoing Assertions will be signed.
All outgoing responses containing Assertions will not be signed.
All outgoing requests/responses not containing Assertions will be signed.
The signing certificate will not be included in the messages.
Identity Federation (acting as the IdP) will not require signatures on any messages except when specified in the SP Partner metadata.
NameIDs, attributes and Assertions will not be encrypted.
Information on the default XML Encryption algorithm is located at http://www.w3.org/TR/2002/REC-xmlenc-core-20021210/Overview.html#aes128-cbc
The hashing algorithm for signatures is SHA-1 by default. Identity Federation can be configured to use SHA-256.
The SAML 2.0 Metadata for the IdP and SP is contained in a single XML document and can be retrieved using the Oracle Access Management Console.
The Metadata can also be retrieved by accessing either of the following URLs:
http://public-oam-host:public-oam-port/oamfed/idp/metadata http://public-oam-host:public-oam-port/oamfed/sp/metadata
The certificates used for signature and encryption operations are published via the SAML 2.0 Metadata. The certificates can be retrieved by using a Service URL that specifies the Key ID of the key/certificate entry as defined in the Keystore Settings. (See Defining Keystore Settings for Federation.) For example,
http://public-oam-host:public-oam-port/oamfed/idp/cert?id=osts_signing
The Provider ID and the Issuer ID of the IdP and SP profiles are identical and can be retrieved from the applicable Provider Partner profile using the Oracle Access Management Console.
Table 37-2 documents the SAML 2.0 URLs for use when Identity Federation is configured to act as an IdP.
Table 37-2 SAML 2.0 URLs for Identity Federation Acting As Identity Provider
| Description | URL |
|---|---|
|
Single Sign On Service URL for HTTP Redirect binding |
http://public-oam-host:public-oam-port/oamfed/idp/samlv20 |
|
Single Sign On Service URL for HTTP POST binding |
http://public-oam-host:public-oam-port/oamfed/idp/samlv20 |
|
Single Sign On Service URL for SOAP binding |
http://public-oam-host:public-oam-port/oamfed/idp/soap |
|
Artifact Resolution Service URL for SOAP binding |
http://public-oam-host:public-oam-port/oamfed/idp/soap |
|
Single Logout Service URL for HTTP Redirect binding |
http://public-oam-host:public-oam-port/oamfed/idp/samlv20 |
|
Single Logout Service URL for HTTP POST binding |
http://public-oam-host:public-oam-port/oamfed/idp/samlv20 |
|
Attribute Authority Service URL for SOAP binding |
http://public-oam-host:public-oam-port/oamfed/aa/soap |
Table 37-3 documents the SAML 2.0 URLs for use when Identity Federation is configured to act as an SP.
Table 37-3 SAML 2.0 URLs for Identity Federation Acting as Service Provider
| Description | URL |
|---|---|
|
Assertion Consumer Service URL for Artifact binding |
http://public-oam-host:public-oam-port/oam/server/fed/sp/sso |
|
Assertion Consumer Service URL for HTTP POST binding |
http://public-oam-host:public-oam-port/oam/server/fed/sp/sso |
|
Single Logout Service URL for HTTP Redirect binding |
http://public-oam-host:public-oam-port/oamfed/sp/samlv20 |
|
Single Logout Service URL for HTTP POST binding |
http://public-oam-host:public-oam-port/oamfed/sp/samlv20 |
Although the standards address the same use case, SAML 2.0 and SAML 1.1 get there in different ways. The most important type of SAML 1.1 request is a query.
A SP makes a query directly to an IdP over a secure back channel (using SOAP). Within the SAML 1.1 protocol, Identity Federation supports the features described in the following sections.
SAML 1.1 profiles rely on pushing SAML artifacts and assertions to an SP to relay authentication information.
The following profiles are supported.
The Browser/Artifact Profile passes a SAML assertion from the IdP to the SP by reference (through the browser using HTTP Redirect). This artifact is subsequently dereferenced through a back-channel exchange in which the SP retrieves the assertion from the IdP using SAML over SOAP over HTTP.
The Browser/POST Profile passes an SSO assertion to an SP through the browser using HTTP POST. We say that the identity provider "pushes" the assertion to the service provider.
The SAML 1.1 specifications do not define a logout profile thus Identity Federation is not able to notify remote partners regarding a user logging out.
When a principal authenticated to one SP requests access to a second site, the second SP can obtain the name identifier and communicate with the first SP regarding the principal - even though no federation for the principal exists between them.
The SAML 1.1 NameID formats listed in Table 37-4 are supported in both IdP and SP mode.
Table 37-4 Supported SAML 1.1 NameID Formats
| NameID Format | Description |
|---|---|
|
urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified |
SP/IdP will use the applicable user attribute to populate/process the NameID value |
|
urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress |
SP/IdP will use the applicable user attribute to populate/process the NameID value |
|
urn:oasis:names:tc:SAML:1.1:nameid-format:X509SubjectName |
SP/IdP will use the applicable user attribute to populate/process the NameID value |
|
urn:oasis:names:tc:SAML:1.1:nameid-format:WindowsDomainQualifiedName |
SP/IdP will use the applicable user attribute to populate/process the NameID value |
|
urn:oasis:names:tc:SAML:2.0:nameid-format:kerberos |
SP/IdP will use the applicable user attribute to populate/process the NameID value |
|
custom value |
When this NameID format is used, OIF/IdP will use a user attribute to populate the NameID value |
Regarding the security of identity data transported using the SAML 1.1 specifications, the following is true.
All outgoing Assertions will be signed.
All outgoing responses containing Assertions will not be signed.
The signing certificate will not be included in the messages.
Identity Federation (acting as the IdP) will not require signatures on any messages.
The hashing algorithm for signatures is SHA-1 by default. Identity Federation can be configured to use SHA-256.
The certificates used for signature and encryption operations can be retrieved by using a Service URL that specifies the Key ID of the key/certificate entry as defined in the Keystore Settings.
For more information, see Defining Keystore Settings for Federation.
For example,
http://public-oam-host:public-oam-port/oamfed/idp/cert?id=osts_signing
The Provider ID and the Issuer ID of the IdP and SP profiles are identical and can be retrieved from the applicable Provider Partner profile using the Oracle Access Management Console.
Table 37-5 documents the SAML 1.1 URLs for use when Identity Federation is configured to act as an IdP.
Table 37-5 SAML 1.1 URLs for Identity Federation Acting As Identity Provider
| Description | URL |
|---|---|
|
Single Sign On Service URL |
http://public-oam-host:public-oam-port/oamfed/idp/samlv11sso |
|
Artifact Resolution Service URL |
http://public-oam-host:public-oam-port/oamfed/idp/soapv11 |
Table 37-6 documents the SAML 1.1 URL for use when Identity Federation is configured to act as an SP.
Table 37-6 SAML 1.1 URL for Identity Federation Acting as Service Provider
| Description | URL |
|---|---|
|
Assertion Consumer Service URL |
http://public-oam-host:public-oam-port/oam/server/fed/sp/sso |
OpenID 2.0 allows users to create accounts with a preferred OpenID IdP and use the account as the basis for signing on to any website that accepts OpenID authentication.
Identity data is communicated through the exchange of an OpenID identifier (a URL or XRI chosen by the end-user) and the IdP provides OpenID authentication. Within the OpenID protocol, Identity Federation supports the functionality described in the following sections.
OpenID 2.0 allows a user to sign into a new web site using a special OpenID URL. For example, if you have a blog at myblog.com, you might have created the OpenID URL, yourname.myblog.com. Then if you navigate to a second web site that accepts OpenID logins and click on the OpenID button, you can type in the URL and click to log in. The second SP discovers the OpenID IdP URL with this OpenID identifier. When the OpenID IdP redirects the authenticated user to the SP, it includes the OpenID Assertion which contains the result of the operation, the NameID of the user and (optional) attributes.
The OpenID 2.0 specifications do not define a logout profile thus Identity Federation is not able to notify remote partners regarding a user logging out.
OpenID defines the NameID as being a random string thus Identity Federation will use one of the following as the value for the NameID.
A hashed user attribute (such as DN)
A generated, random value that will be stored in the Federation Data Store; this mode requires the use of a Federation Data Store
Regarding the security of identity data transported using the OpenID 2.0 specifications,the following is true.
All outgoing Assertions will be signed.
The default Association Algorithm is HMAC SHA-1.
The default Session Agreement Algorithm is Diffie-Hellmann SHA-1.
OpenID is an extensible specification. The following extensions are available when using the integrated Identity Federation.
Attribute Exchange (AX): If enabled, a SP can request attributes to be included in the OpenID Assertion response. The IdP can include the requested attributes or attributes configured to be in the response. (Default: enabled)
Provider Authentication Policy Extension (PAPE): If enabled, advanced authentication methods can be defined and specified. This might include, for example, a phishing-resistant authentication method or multi-factor authentication. (Default: disabled)
GSA Level 1: identifier in the OpenID Assertion indicating if this server is compliant with the http://www.idmanagement.gov/schema/2009/05/icam/openid-trust-level1.pdf policy. If enabled and if PAPE is enabled, OIF will include this policy in the OpenID response (Default: disabled)
Level Of Assurance (LOA): identifier in the OpenID Assertion indicating if this server is compliant with the http://csrc.nist.gov/publications/nistpubs/800-63/SP800-63V1_0_2.pdf policy. If enabled, OIF/IdP will use the mapping between Level of Assurance and schemeID to determine the value to use for LOA in the OpenID response (see 2.5.2 for more information) (Default: disabled)
No Private Identifier Information (NoPII): identifier in the OpenID Assertion indicating if this server is compliant with the http://www.idmanagement.gov/schema/2009/05/icam/no-pii.pdf policy. Note, if enabled, OIF will not include attributes in the OpenID Assertion
Persistent Personal Identifier (PPID): identifier in the OpenID Assertion indicating if this server is compliant with the http://schemas.xmlsoap.org/ws/2005/05/identity/claims/privatepersonalidentifier policy. If enabled and if PAPE is enabled, OIF will include this policy in the OpenID response (Default: disabled)
Registration (SReg): extension for attributes in the OpenID Assertion. If enabled, the SP can request attributes to be included in the response, and the IdP can include requested attributes or attributes configured to be in the response (Default: disabled)
UI Extension (UIExt): extension for UI. In OIF/IdP, support for this extension is limited to advertisement in the XRDS metadata (Default: disabled)
The following URL is the realm of the OpenID 2.0 SP component.
http://public-oam-host:public-oam-port
Table 37-7 documents the OpenID 2.0 URLs for use when Identity Federation is configured to act as an IdP.
Table 37-7 OpenID 2.0 URLs for Identity Federation Acting As Identity Provider
| Description | URL |
|---|---|
|
Single Sign On Service URL |
http://public-oam-host:public-oam-port/oamfed/idp/openidv20 |
|
Discovery Service URL |
http://public-oam-host:public-oam-port/oamfed/idp/openidv20 |
Table 37-8 documents the OpenID 2.0 URLs for use when Identity Federation is configured to act as an SP.
Table 37-8 OpenID 2.0 URLs for Identity Federation Acting as Service Provider
| Description | URL |
|---|---|
|
Single Sign On Service URL |
http://public-oam-host:public-oam-port/oam/server/fed/sp/sso |
|
Discovery Service URL |
http://public-oam-host:public-oam-port/oamfed/sp/openidv20 |
|
Realm URL |
http://public-oam-host:public-oam-port |
Access Manager now supports features of the WS-Federation 1.1 protocol.
WS-Federation 1.1 partners can be created using the new addWSFed11IdPFederationPartner and addWSFed11SPFederationPartner WLST commands. After creating the partners, the profiles can be configured using the existing WLST Identity Federation commands. For details, see the Oracle Fusion Middleware WebLogic Scripting Tool Command Reference for Identity and Access Management.
Note:
Partial administration of the WS-Federation 1.1 partners is available using the Oracle Access Management Console.