While you can use SAML tokens, Username Tokens (UNT), or JSON Web Tokens (JWT) to establish trust between services, Oracle recommends using SAML-based client policies. SAML is an XML-based, open-standard data format for exchanging authentication and authorization data between parties, in particular, between an identity provider and a service provider.
Why Use SAML?
When you use a SAML token, the identity of the user who is signed in to an extension service hosted application is propagated automatically to the SaaS application.
When you use a SAML token, the SaaS application applies the authorization rules for the signed-in user when processing web service calls.
When Java Cloud Service - SaaS Extension is established as the Identity Provider, it authenticates the requests from associated Service Providers and establishes the user identity; that identity is then used as the basis for authorization. SAML is typically used with web service messaging between associated services. Associated Oracle Cloud services can use Oracle Web Service Manager (OWSM) for SAML authentication. OWSM is shipped with the Oracle SaaS application and provides a menu of security policies, including SAML-based policies, for developers to leverage when making web service calls between services. See Securing JAX-WS Web Services.
To a large extent, SAML automates token-building. These client policies are an effective alternative to building tokens that usually contain user name and password attributes formatted to some specification. With SAML, a preconfigured SAML infrastructure is presumed. On the client side, SAML tokens are included in outbound web service requests automatically, and a SAML login module knows how to deconstruct the token for authentication purposes. In many respects, SAML token-based policies can be the easiest to implement, as Oracle provides a working SAML infrastructure.
To successfully propagate identities, Java Cloud Service - SaaS Extension and the SaaS application must exist in the same identity domain. When service instances are provisioned in the same identity domain, they are usually automatically associated, which enables SAML-based identity propagation between Java Cloud Service - SaaS Extension and the SaaS application and enables SSO capability with the SaaS application acting as the identity provider. Developers can leverage SAML-based security policies that will automatically use the current logged-in user of the SaaS application to invoke the web service in Java Cloud Service - SaaS Extension. Associated services have this SAML trust pre-established by Oracle. The association is automatic when you purchase a new Java Cloud Service - SaaS Extension instance to be used with an existing SaaS instance or when you purchase a SaaS application and Java Cloud Service - SaaS Extension instance at the same time.
This policy enables message protection (integrity and confidentiality) and SAML token population for outbound SOAP requests using mechanisms described in WS-Security 1.1. A SAML token is included in the SOAP message for use in SAML based authentication with sender vouches confirmation.
This policy includes SAML tokens in outbound SOAP request messages. The SAML token with confirmation method Bearer is created automatically. The policy also verifies that the transport protocol provides SSL message protection. This policy can be attached to any SOAP-based client.
This policy enforces message protection (integrity and confidentiality) and one of the following authentication policies:
SAML-based authentication for inbound SOAP requests in accordance with the WS-Security 1.1 standard.
SAML-based authentication using credentials provided in SAML tokens with confirmation method 'Bearer' in the WS-Security SOAP header. Verifies that the transport protocol provides SSL message protection.
Sample Use Cases
You can find two sample use cases for propagating ID with SAML in Writing a Client That Can Access an Oracle Sales Cloud Application and Writing a Web Service that an Oracle Sales Cloud Application Can Access.