X

Tips and HowTos for Single Sign-On & Federation Oracle Identity Management Integrations

  • May 31, 2017

Identity Cloud Service & SAML

Identity Cloud Service or IDCS provides Identity Management capabilities hosted in the Cloud to Oracle customers, including:

  • User & Group Management
  • SAML SSO with SAML SPs and IdPs
  • OpenID Connect SSO with SPs
  • ....

In today’s article, I will be going over the SAML features supported by IDCS 17.2.2 and later.

SAML Support

Protocol

The following SAML 2.0 protocols and bindings are supported by IDCS:

  • SAML 2.0 SSO Protocol
    • Sending and receiving of the SAML AuthnRequest via HTTP-Redirect or HTTP-POST bindings
    • Sending and receiving of the SAML Response containing the SAML Assertion via the HTTP-POST binding
  • SAML 2.0 Logout Protocol
    • Sending and receiving of the SAML LogoutRequest via HTTP-Redirect or HTTP-POST bindings
    • Sending and receiving of the SAML LogoutResponse via HTTP-Redirect or HTTP-POST bindings
  • SAML 2.0 Metadata
    • The IDCS SAML Service can generate a SAML 2.0 Metadata document listing the services and certificates used for Federation SSO
    • The IDCS SAML Service can also consume a SAML 2.0 Metadata during Federation trust establishment.

Cryptography

The IDCS SAML service supports the following cryptographic features:

  • SHA-256 and SHA-1 as the signature hash algorithm
  • The inclusion of the IDCS Signing Certificate in outgoing SAML messages, when the message is sent using the HTTP-POST binding
  • When IDCS is acting as a SAML IdP during the SAML Assertion Generation:
    • Either the SAML Response or the SAML Assertion will be signed
    • The SAML Assertion can be encrypted using AES-128-CBC, AES-192-CBC, AES-256-CBC or 3DES-CBC
  • When IDCS is acting as a SAML SP during the SAML Assertion Consumption:
    • Either the SAML Response or the SAML Assertion must be signed

SAML Assertion Generation

As an IdP, IDCS supports the following when issuing a SAML 2.0 Assertion

  • NameID Format
    • urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified
    • urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress
    • urn:oasis:names:tc:SAML:1.1:nameid-format:X509SubjectName
    • urn:oasis:names:tc:SAML:1.1:nameid-format:WindowsDomainQualifiedName
    • urn:oasis:names:tc:SAML:2.0:nameid-format:kerberos
    • urn:oasis:names:tc:SAML:2.0:nameid-format:persistent
    • urn:oasis:names:tc:SAML:2.0:nameid-format:transient
    • Custom NameID format
  • NameID Value
    • Username or Primary Email user attribute stored in the Identity Store for any NameID format except urn:oasis:names:tc:SAML:2.0:nameid-format:transient
    • For urn:oasis:names:tc:SAML:2.0:nameid-format:transient, a one-time random identifier
  • SAML Attributes
    • The following user attributes stored in the Identity Store
      • Username
      • Given Name
      • Middle Name
      • Family Name
      • Primary Email Address
      • Work Email Address
      • Phone Numbers (home, mobile, work)
      • Title
      • Work Address attributes
      • User Groups
    • The SAML Attribute name can be set by the administrator
  • The SAML Assertion will contain an attribute that will hold of the Identity Domain name:
    • Name: oracle:cloud:identity:domain
    • Value: the customer's identity domain name

SAML Assertion Consumption

As an SP, IDCS will validate the incoming SAML Assertion and map it to an IDCS user record. The service supports the following:

  • NameID Format
    • urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified
    • urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress
    • urn:oasis:names:tc:SAML:1.1:nameid-format:X509SubjectName
    • urn:oasis:names:tc:SAML:1.1:nameid-format:WindowsDomainQualifiedName
    • urn:oasis:names:tc:SAML:2.0:nameid-format:kerberos
    • urn:oasis:names:tc:SAML:2.0:nameid-format:persistent
    • urn:oasis:names:tc:SAML:2.0:nameid-format:transient
    • Custom NameID format
  • Assertion Mapping
    • Either based on the NameID contained in the Assertion that will be mapped to a user record attribute in the Identity Store
    • Or based on a SAML Attribute contained in the Assertion that will be mapped to a user record attribute in the Identity Store
    • The information from the SAML Assertion will be mapped to one of those user record attributes:
      • Username
      • Display Name
      • Given Name
      • Middle Name
      • Family Name
      • Primary Email Address
      • Any other email addresses (home, work, other, recovery)

Endpoints

The services implementing the SAML 2.0 protocol are published at:

  • /fed/v1/idp/sso for the IdP Single Sign On Service, where the SP redirects the user with the SAML AuthnRequest to the IdP
  • /fed/v1/idp/slo for the IdP Single Logout Service, where the SP redirects the user with the SAML LogoutRequest or LogoutResponse to the IdP
  • /fed/v1/sp/sso for the SP Assertion Consumer Service, where the IdP redirects the user with the SAML Response containing the SAML Assertion to the SP
  • /fed/v1/sp/slo for the SP Single Logout Service, where the IdP redirects the user with the SAML LogoutRequest or LogoutResponse to the SP
  • /fed/v1/metadata for the SAML 2.0 Metadata

The SAML service also provides two endpoints to initiate a Federation SSO operation, ignoring whether or not the user is already authenticated at the target SP domain. As a consequence, these flows should not be primarily used, and instead the user should be sent to the target SSO service which will determine whether or not an authentication involving Federation SSO is required. Both SAML services (IdP or SP) support starting a Federation SSO:

  • IdP Initiated SSO:
    • Endpoint: /fed/v1/idp/initiatesso
    • Query Parameters (one of providerid, partnerguid or partnername is required; returnurl is optional)
      • providerid: the SP ProviderID
      • partnername: the name of the SP as registered in IDCS
      • partnerguid: the unique GUID of the SP as registered in IDCS
      • returnurl: the location where the user should be redirected after the Federation SSO is completed
  • SP Initiated SSO:
    • Endpoint: /fed/v1/sp/initiatesso
    • Query Parameters (one of providerid, partnerguid or partnername is required; returnurl is optional)
      • providerid: the IdP ProviderID
      • partnername: the name of the IdP as registered in IDCS
      • partnerguid: the unique GUID of the IdP as registered in IDCS
      • returnurl: the location where the user should be redirected after the Federation SSO is completed

Cheers,
Damien Carru

Be the first to comment

Comments ( 0 )
Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.