Re: Identity Provider Initiated SSO2 with SAML2 - ABAP 7.4 - How ?

Hey Phil ol chum,

IdP Initiated SSO is 100% possible in this scenario on NetWeaver 740, as we both now know with a recent customer implementation.  Looking over the above comments let me add a couple of things:

“ You need an identity provider in your landscape. “

Customers generally have a commercial IdP ( there a many, an example is Microsoft ADFS ).

If there is no IdP you can always construct the SAML2 Assertions and wrap them in a SAMLP response document.  In this case the IdP is something that can construct the SAML2 assertion, sign it correctly and has the appropriate security control around the certificates ( e.g. you have an X.509 cert + signing cert in the SAML2 Assertion, where do you keep the private keys for this if you have a custom solution? ).

In a nutshell, IDP Initiated SSO means:

• End user WANTS to request a resource in SAP
• A SAML2 Assertion is constructed, signed etc.  nb: no request is made at this point
• The SAML2 Assertion is passed with the request
• SAP interprets the SAML2 Assertion
• User context roll-in if successful
• User is presented the resource from SAP

What this is trying to do is avoid the front/back channel communication step:

1) contact SAP

2) contact IDP

3) hand-shake

4) issue assertion

5) interpret assertion

6) user context roll in ( I think this is roughly correct in terms of sequence ).

Front Channel:

http://help.sap.com/saphelp_nw70ehp2/helpdata/en/4a/b5b9f222526d6de10000000a42189c/content.htm

Back Channel:

http://help.sap.com/saphelp_nw70ehp2/helpdata/en/4a/b5bab122526d6de10000000a42189c/content.htm?frameset=/en/4a/b5b9f222526d6de10000000a42189c/frameset.htm

Instead, you request a resource from SAP with an already formed and signed SAML2 Assertion and presto.. you’re in mate.

Caveat

I’m sure there are other ways to do this, this way worked for us. NB: pay attention to security requirements for this stuff, should be vetted by security architecture etc.

SAP Configuration Steps Required:

There are a few variations here that are dependent on your individual scenarios, but this is a baseline that worked for me:

Steps 3 to 13 all occur in the web based application after running transaction SAML2.

1. 1) Activate SAML2 ICF nodes
2. 2) Active PSE etc ( security environment )
3. 3) Create Local Provider ( transaction SAML2 )
4. 4) By creating the Local Provider you automatically create the SAML2 entries in STRUST
5. 5) Use HTTP Post bindings for Assertion Consumer Service
6. 6) Create Trusted Provider
7. 7) HTTP for single sign-on endpoint and use a dummy url here as Location URL i.e. if SAML2 fails, redirect to this URL
8. 8) UNSPECIFIED for Trusted Provider Supported NameID formats
9. 9) Assertion Subject NameID for User ID Source
10. 10) I’ve used “Login ID” successfully for NameID format for UNSPECIFIED
11. 11) For signature and Encryption, you can create a certificate / signing certificate key pair.  Here I think we used MAKECERT, and someone passed me the signing certificate and I imported at this step
    1. a. SSO Auth Request  sign= Always
    2. b. SSO Assertions require signature = Always
    3. c. SSO Response require signature  = never
    4. d. SSO Response require encrypted elements = No
12. 12) Did not create an Policies
13. 13) Did not create any Authentication Requirements
14. 14) Ensure your ICF node of the app you are trying to access includes the logon procedure for SAML2 authentication

Security Trace

<host>/sap/bc/webdynpro/sap/sec_diag_tool?sap-client-100=sap-language=EN#

This trace tool will become your best friend.  Make sure it’s corresponding ICF node is activate and in your SAML2 configuration, debugging is switched to ON.  It will help you understand what’s gone wrong during the interpretation of the Assertion.

Construction of SAML2 Assertion

I’m going to have to write a blog entry for this, this is the hardest part.  As you know we achieved this in a .net environment via code.  I can’t post details of that particular coding task here because of commercial sensitivity but we know it’s achievable, I’ll try and cover this in the blog.

Watch out for encoding the response xml, you have to BASE64 encode first then URL encode second.

Other Notes:

SAP does a lot of things via CL_HTTP_EXT_SAML20 handler class.  Also be aware of the XSLT transformations that take place as well. Half the battle is getting the Samlp:Response and the entire xml document in a format where SAP’s XSLT runs correctly.  In this regard, look under package SAML2_CORE all transformations are there that you need to adhere to.

Final Thoughts

IdP Initiated SSO is possible, you don’t necessarily need a commercial IdP, as long as you can send the SAML2 response and assertion during a POST to SAP, you should be able to get straight in without he front/back channel communication step.

This is obviously not an exhaustive list of configuration steps but there are many challenges which I’ll cover in a future blog, particularly around construction of the SAMLP response and assertion.

Cheers

Leigh