#SAML
Security Assertion Markup Language (SAML) is an XML based, open-standard data format for exchanging authentication and authorization data. SAML 2.0 is a standard for communication of assertions about principals typically users. The assertion can include the means by which a subject was authenticated, attributes associated with the subject and an attributes associated with the subject and an authorization decision for a given resource. The two main components of a SAML 2.0 landscape are an identity provider and a service or resource provider. The service or resource provider is a system entity that provide a set of applications with a common session management, identity management and trust management. The identity provider is a system entity that manages identity information for principals and provides authentication services to other trusted service provider. In other words, the service providers outsource the job of authenticating the user to the identity provider.
In case of SAML 2.0, the client application will request for the resource from the Service provider (in our case it will be Management Accounting Service in HCP). The Service provider will redirect the call to the configured IDP (SAP ID Service). The client will then perform a security challenge to the IDP. The IDP will return the authentication mechanism (Basic, X509 Certificate, NTLM) that can be used by the client to authenticate to the IDP (in our case we will be using Form based authentication for authenticating to the IDP). Once the call is authenticated by the IDP, the call will be redirected to ACS (Assertion connectivity service) endpoint along with the SAML artifact. The client would have to then connect to the ACS endpoint with the SAML artifact & SAML cookie received during its call to the Resource Provider. ACS will then connect to the IDP to validate the artifact received and once the artifact has been validated the call we be re-directed to the original requested resource. The client can then redirect the call to the resource endpoint with SAML artifact. The service provider will then authenticate the call and return the client with the SAML secure cookie which can be used by the client in further communications till the time SAML cookie expires.
All the calls required for SAML authentication would be enabled via a JavaScript policy. SAML 2.0 supports multiple binding and the IDP would support multiple authentication scheme. In this document we have considered only the SAML Post Binding and Form based authentication for authentication with the IDP. The high level design for the JavaScript policy that we have is described as follows:-
In this example, the SAP RealSpend Service from SAP HANA Cloud Platform has been used, the details of this service is available in SCN.
In the config.js JavaScript, provide your SCN user credential which should be used to trigger the SAML flow.
Click here for more details on JavaScript Policy