Identity Federation

Identity Federation :- The Identity Federation service is an integral part of the Oracle Access Management platform, leveraging the authentication core services  such as credential collectors and authentication plug-ins.
Identity Federation services can protect both on-premise and cloud resources leveraging several industry standards:

•  SAML-based federation (authentication, attribute sharing)
•  OpenID-based federation (delegated authentication) 
•  OAuth-based federation (delegated authorization) 
•  Social-identity-based federation (redirected authentication) 
•  Form-fill-based federation (Access Portal) 

 Identity Federation services are enabled from the central access management console,

Identity Federation services are seamlessly weaved into the authentication and authorization process.

Identity Federation leverages the Access Management platform’s shared services.

SAML-Based Federation :-The Security Assertion Markup Language (SAML) is an open framework for sharing security information on the Internet through XML documents.
SAML was originally designed to address the following requirements:

•  Limitations of web browser cookies to a single domain: SAML provides a standard way to transfer security information across multiple Internet domains (Note: Cross domain SSO can be supported by Oracle Access Management (without federation) if all domains leverage the same Access Management server – in all other cases, Access Management Identity Federation is required).
•  Proprietary web single sign-on (SSO): SAML provides a standard way to implement SSO within a single domain or across multiple domains. 
• Federation: SAML facilitates identity management (e.g., account linking when a single user is known to multiple web sites under different identities). 
• Web Services Security: SAML provides a standard security token (a SAML assertion) that can be used with standard web services security frameworks (e.g., WS-Security, WS-Trust, etc.). 
• Identity propagation: SAML provides a standard way to represent a security token that can be passed across the multiple steps of a business process or transaction. 

Typically, SAML involves two parties: 

• Identity Provider (IdP): Asserting party that provides identity information to other services. 
• Service Provider (SP): Relying party that consumes the identity information sent by the asserting party to grant access to services hosted by the SP. 

Oracle Access Management Identity Federation supports a large set of use-case scenarios: 

•  Known name or attribute: Email address, X.509 Subject Name, Windows Domain Qualified Name, Kerberos Principal name, Attribute (e.g., employee number). 
• Opaque identifier: The principal is identified by a persistent randomized string private to the identity provider and service provider pairs. 
• Anonymous user: The principal is never explicitly identified by a persistent identifier, i.e., there’s no need to maintain a user (principal) entry at the service provider. 
•  Attribute Sharing: Identity Federation’s attribute-sharing plug-in allows Oracle Access Management to request user attributes from an identity provider. 
• Identity Provider Proxy: This use case involves three parties: Original Service Provider; Proxying Identity Provider (Oracle Access Management Federation acting as Identity Provider and becoming a Service Provider); and Proxied Identity Provider (Oracle Access Management services that authenticate the user). 

Oracle Access Management Fedlet :- 

Fedlet provides a standalone, light-weight SAML 2.0-compliant component for a Service Provider (SP) interacting with Access Management Identity Federation or a third-party SAML Identity Provider (IdP). 

Fedlet can be embedded and integrated with an application at development time. Fedlet can be deployed on premise or in the cloud supporting multiple environments: 

• Java version deployable as a Web Archive (WAR) on Oracle WebLogic Server and other market-leading Java EE containers. 
•  .NET version designed to support asp.net applications, deployable to Microsoft IIS (DLL) . 

Additionally, Fedlet can be deployed in conjunction with an IdP Discovery Service allowing users to select a preferred IdP. 

OpenID-Based Delegated Authentication :-

OpenID is a delegated authentication standard that any web site can leverage without having to develop its own authentication system. As a user, the OpenID standard allows you to log in to multiple OpenID-enabled sites with a single OpenID token. Identity data is communicated through the exchange of an OpenID identifier (a URL or XRI chosen by the end-user) and the Identity Provider provides OpenID authentication. Oracle Access Management Identity Federation support the following functionality: 

• OpenID 2.0 Authentication and SSO: An OpenID token contains the NameID of the user and (optional) attributes, outgoing tokens (or “assertions”) are signed.
•  OpenID 2.0 NameID Format: OpenID defines the NameID as being a random string. Identity Federation uses one of the following as the value for the NameID: A hashed user attribute (such as DN); a generated random value stored in the Federation Data Store (requires the use of a Federation Data Store). 

OAuth Delegated Authorization 

OAuth (Open Authorization) is an industry standard designed to support delegated authorization. Before OAuth, if a third-party (e.g., a money manager) wanted to access your account, you’d have to share your credentials with them, thus compromising your environment. 

OAuth was originally designed to allow a User (Resource Owner) to transparently share his private data stored on one site (Service Provider, or Resource Server) with another site (Consumer, or Client). 

With the advent of OAuth 2.0, the original consumer-centric delegated authorization use case extends to the enterprise and the cloud. OAuth 2.0 enables a third-party application to obtain access on its own behalf (two-legged process) or obtain limited access to an HTTP service on behalf of a Resource Owner by orchestrating an approval interaction between the Resource Owner and the HTTP Service Provider (three-legged process).

Although focusing on mobile clients, OAuth was originally intended for web applications that need access to resources owned by private users.

Oracle Access Management’s Support for OAuth 

OAuth is supported by multiple Oracle Access Management services: 

• Oracle Access Management Identity Federation (license for web clients only (i.e., non-mobile)). Oracle Access Management Mobile and Social (license for both web clients and mobile clients). Oracle API Gateway (typically, OAG acts as the resource server while the Oracle Access Management OAuth service acts as the authorization server; an OAG filter validates the Access Management OAuth token before allowing access to the resource). 
• Web Services Manager (future release): OAuth client-side support and integration with Oracle Access Management OAuth service for obtaining an access token, propagating it to a WSM-protected resource, and verifying the access token on the service side. 

Identity Federation OAuth Service 

The Identity Federation OAuth service extends the Access Management server (both administration and runtime) to provide Token Issuance, Token Validation, Token Revocation and User Flows in accordance with the OAuth 2.0 standard. The OAuth service increases security by eliminating the use of end-user passwords in many service-toservice interactions and reduces administrative costs by centralizing trust policies and associations in a large deployment. 

The standard OAuth Service is implicitly enabled if the Oracle Access Management Identity Federation service is enabled, To also enable Mobile OAuth, the Mobile and Social service (described later in this document) must be enabled, in addition to the Identity Federation service.

 Oracle Access Management Cloud Federation 

•  Microsoft Office 365 SAML 2.0 federation: Oracle Access Management Identity Federation is the Identity Provider, MS Office 365 is the Service Provider 
• WS-Federation Passive Requester Profile: Cross-domain Web SSO (HTTP Redirect, HTTP Post), local log out supported (i.e., log out is not broadcast to all WS-Federation endpoints in the circle of trust). 
• Web Services and APIs Security: Support for federation and delegated authorization with Salesforce, Google, Amazon AWS, SQS.

For Technical Implementation please refer my other blogs