What token types are supported with SAP’s Identity Provider? How can I move away from Logon Tickets?
These two are among the most common questions that we receive from customers. It seems high time that we cover them in a blog. Before we delve into the details though, let us quickly recap the main functions of an identity provider.
An identity provider is made up of two major components. One is the Identity Provider (IdP) for web-based authentication, Single Sign-On and identity federation. The other is the Security Token Service (STS), which does the same thing but only in web service based scenarios.
So an IdP will do authentication and Single Sign-On for an end user accessing functionality via the web, e.g. a browser or a Portal. The STS will perform authentication and Single Sign-On for web service based scenarios, where no user interaction takes place and systems talk to each other.
Both scenarios share the same standard that the industry has developed, which is called Security Assertion Markup Language (SAML). At the core of the user verification and Single Sign-On is a so-called SAML assertion which serves as the mechanism for authentication and Single Sign-On.
To explain it extremely short and concise during the process of executing backend functionality (in SAML lingo this is an app running on the service provider) a user or a web service gets redirected to the IdP (in case of the user) or to the STS (in case of the web service), where the credentials are verified and a SAML assertion is issued which can then be used to access the backend functionality on the service provider (e.g. an SAP backend). For more details on the SAML standard, check out the industry consortium web page at Oasis https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=security.
SAP views SAML as the main strategic mechanism for web-based and web service based Single Sign-On and strongly recommends customers to check out and implement this standard where possible. But let’s read on to understand benefits and capabilities.
Why SAML? SAML has a few advantages and features that other security tokens do not offer. For example via SAML you can implement cross-domain authentication and Single Sign-On. This might be of interest to customers that want their end users to log on from various domains some of which might lie outside of the company’s firewall. And you can configure inter-company Single Sign-On, so that your suppliers’ end users can also get secure authentication and Single Sign-On from another company’s domain.
Another advantage is identity federation. This is a new capability that can only be realized via the SAML standard. At the heart it means that you can federate identities between systems, which makes user administration less costly and easier.
Then SAML is an industry standard which means that vendors belonging to the OASIS consortium have jointly developed this standard. So if customers want to implement authentication and Single Sign-On involving different systems from different vendors, they can rely on the same standard and proven interoperability via so-called interoperability tests, which were first conducted by Liberty Alliance and now by Kantara. SAP participated with our SAP NetWeaver Identity Provider twice.
So what options do I have in terms of security tokens?
To answer this question correctly we need to look at the input side first. So what credentials do the IdP and STS from SAP NetWeaver Identity Provider accept as a means of authenticating and providing credentials towards the Idp and STS? Or in other words what are the tokens that the IdP and the STS accept as the end user’s or web service credentials to prove their identity? SAP’s NetWeaver Identity Provider supports User ID and password, X.509 certificates, Logon Tickets and SAML assertions from another Identity Provider as the initial authentication and credential verification with both its IdP and STS. In addition you can configure so-called login modules to accept other credentials like SPNEGO Kerberos and LDAP authentication. This set should cover your entire landscape in web based or web service based scenarios.
Now let us look at the outgoing side? Which tokens can the SAP NetWeaver Identity Provider issue, after a successful verification of initial authentication has happened? Here the answer differs for the IdP or the STS.
The IdP from SAP NetWeaver Identity Provider can issue a SAML assertion and a Logon Ticket. If your backend does not support either, we can also forward user ID and password, which need to be maintained in the IdP. However, with either a SAML assertion or a Logon Ticket you should get very far in establishing company wide web based authentication and Single Sign-On. SAML will help you with all SAP systems on higher releases and non-SAP systems and Logon Tickets you can send to SAP systems of lower releases.
The STS can generate X.509 certificates in addition to SAML assertions, Logon Tickets or user ID and password, which should also cover your entire landscape.
To sum it up, SAP NetWeaver Identity Provider offers proven interoperability via SAML (and the successful completion of the interoperability tests), allows a multitude of standardized and/or international authentication mechanisms and supports even Logon Tickets for SAP systems on lower releases, which no other vendor does. We recommend that you leverage SAP NetWeaver Identity Provider, which gets shipped either via SAP NetWeaver Identity Management or SAP NetWeaver Single Sign-On, to implement SAML for authentication and Single Sign-On in web-based or web service based scenarios.
For more information on SAP NetWeaver Identity Provider, please check out our TechEd sessions here http://www.sapteched.com/ or SCN.
Any questions?
Thanks a lot and kind regards,
Gerlinde Zibulski
