Application Development Discussions
Join the discussions or start your own on all things application development, including tools and APIs, programming models, and keeping your skills sharp.
cancel
Showing results for 
Search instead for 
Did you mean: 

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

phil_soady
Participant
0 Kudos

How can we on ABAP 7.40 system authenticate a SAML assertion with X.509 payload.

The root certificate can be loaded as per x.509 log on scenarios.

X.509 ticket use with users managing personal key store is not an option.

SAML2 IP initiated SSO2 has been approved. And is used with other software vendors at the site. Eg Salesforce

I can only find SAP documentation such as

http://wiki.scn.sap.com/wiki/display/Security/Single+Sign-On+with+SAML+2.0+and+ABAP+Systems+Supporti...

and

http://help.sap.com/saphelp_nw70ehp2/helpdata/en/46/631b92250b4fc1855686b4ce0f2f33/content.htm

which are different scenarios

SAP is not the SAML2 ID provider.

The SAML2 provider is an initiator as per SAML 1.1.  But SAML2 is no used.

We want to use the scenario IP initiation SSO via SAML2.

See section 5.1.4 of the SAML standard

https://www.oasis-open.org/committees/download.php/27819/sstc-saml-tech-overview-2.0-cd-02.pdf

This is a valid and documented STANDARD.

How to in SAP 7.40 ABAP.   ?

sample

saml:Assertion ID="Assertion-uuida5f692cd-0140-128b-92fa-fb8c3748ef02" IssueInstant="2013-08-22T12:18:54Z" Version="2.0" xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">    etc

1 ACCEPTED SOLUTION

leigh_mason
Employee
Employee

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?frame...

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. 😎 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

5 REPLIES 5

mvoros
Active Contributor
0 Kudos

Hi,

I haven't tried this so I am guessing here. BU I would try to implement standard service provide initiated SSO with front-channel communication. In OASIS spec in section 5.1.4 the fifth step is to call Assertion Consumer Service using HTTP POST. This is implemented in SICF service saml2. So I would try to set up your IdP to call this service and debug this service to see what is happening.

I would also check Automatic User Account Creation and Update using SAML 2.0 in AS ABAP - Security and Identity Managem... This scenario is also IdP initiated but it also creates a new user. So it should be possible to use it as a template and omit user creation step.

Cheers

Former Member
0 Kudos

Hi Phil,

for SAML 2 on 7.40 please check the docs on SAML 2. IdP initiated SSO is often also called IdP unsolicited SSO or SAML 2 using unsolicited responses. In the end, only the first roundtrip between browser and SP will be skipped. Without really having any info on your scenario, I would also guess it could work.

Have you just tried to enable SAML2 authentication per the documentation and sent your request to the ABAP system.

Regards,

Patrick

MichaelShea
Product and Topic Expert
Product and Topic Expert
0 Kudos

Hi Phil,

The AS ABAP can only function as a service provider. You need an identity provider in your landscape. You can use any SAML 2 compliant identity provider. SAP also offers an identity provider as part of the SAP NetWeaver Single Sign-On product. See http://help.sap.com/nwsso.

As to how use federation with X.509, you'll need to map the users in table USREXTID. See the documentation: Configuring Federation Type Persistent Users - User Authentication and Single Sign-On - SAP Library

To do the mapping you'll have to implement a BAdI. SAP provides a mass configruation report to do the mapping.

Mapping Users in Table USREXTID - User Authentication and Single Sign-On - SAP Library

leigh_mason
Employee
Employee

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?frame...

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. 😎 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

0 Kudos

Nice work Leigh