Part 5: BETA SAP CP Member Provisioning via Microsoft ADFS

[JakobMoellers]

This is part 5 of my blog series about cloud architecture on SAP Cloud Platform (SAP CP from now on). You can find the overview page here.

A few weeks ago, the SAP Cloud Platform Development Team released a great new feature (currently still beta): you could use SAP Cloud Platform Identity Authentication (SCI) not only as an identity provider for application users, but also for SAP CP Members (to learn about the difference, read through this blog article). I was quite excited about that because I saw a challenge for me: use this new mechanism to not only provide Members from SCI, but actually from a Microsoft ADFS. What's the big deal about this? Well, many of my customers have all their administrators (and developers) maintained in their Active Directory and they have already implemented Single Sign On (SSO) with ADFS. If I could find a way to integrate ADFS with the new SAP CP Member provisioning method, that would mean that my customers don't have to manage the S-Users for SAP CP on top of their "normal" IT administrators and developers but could use their established user management methods to at least authenticate SAP CP Members.

The overall concept is depicted in this figure:



The Member is accessing the SAP CP Sub-Account with the browser (1). The Sub-Account is redirecting the user to the trusted Platform Identity Provider (SAP Cloud Platform Identity Authentication (SCI)) (2). SCI is acting as a proxy for the corporate identity provider (manual) and forwards the user to the Microsoft ADFS (3). The Member is logging in with his/her corporate user credentials (or using SSO if configured correctly in ADFS) and receives his valid SAML authentication token (4). The Member can then use the SAML authentication token to access the SAP CP Sub-Account (5).

To make it short: this concept works and my customers are using it. However, as it's still a beta functionality (10.03.2017), you have to be careful with productive usage. Also, keep in mind that even when you use a separate/external Platform Identity Provider, you should keep some Members from the SAP ID-Service (e.g. S-Users) in the Sub-Accounts for fallback. Otherwise, it will be difficult to access your Sub-Accounts if there is a problem with SCI, ADFS, or AD.

I don't want to give a step-by-step manual for the configuration of the scenario, because the individual steps are already described in the official documentation but just give you the general steps you should conduct to implement the concept. I would recommend the following:

1. Configure your SCI tenant to be the Platform Identity Provider of your SAP CP Sub-Account. This is described here.


2. This configuration will create a new application in your SCI tenant. For better overview, I would rename this new application so that you know that it is the application for the Members and NOT the application for the Application Users. (If you use SCI for both Members and Application Users, you'll have two different applications in the SCI configuration (which is good and necessary!). If you don't know the difference between Members and Application Users, read my other article).


3. Establish a bidirectional trust relationship between SCI and ADFS. Therefore, add a new "Corporate Identity Provider" to SCI (described here) and make sure to select "MS ADFS 2.0" as "Identity Provider Type". This is extremely important because if you selected "SAML 2.0 Compliant", SCI would include a SAML-property ("<scoping>") for the proxy-redirect which ADFS does not understand (yet). So make sure you select ADFS here!
   


4. Add SCI as a trusted service provider in ADFS (consult your ADFS team or documentation).


5. Configure the new application from step 2 in the SCI Cockpit to use your new "Corporate Identity Provider" (ADFS) as "Identity Provider". This is described here.


6. Add a new Member, which is provided by ADFS, to your SAP CP Sub-Account. This is described here.


7. Test whether you can logon to your SAP CP Sub-Account by accessing this URL (described here😞
   https://account-<account-id>.hana.ondemand.com/cockpit

If you configured everything correctly, you'll be redirected to the logon-page of your ADFS. Most likely however, you'll not be able access the Cloud Platform Cockpit after a successful authentication in your ADFS because the SAML response from ADFS (step 4 in my figure) is not in the format which the SAP Cloud Platform Cockpit understands.

I debugged this intensively with a SAML plugin in my browser and compared the SAML response from SCI with the SAML response from ADFS. I then altered the SAML response from ADFS so that it returns the exact same attributes as the SCI would normally do. With the response altered (ADFS is quite flexible here), I could logon to the Cloud Cockpit. Most likely, everyone will have different challenges here because of different ADFS configurations, but for me, the following changes to the SAML response from ADFS were necessary:

• The nameid of the user (=Member name) must not include the AD-domain. So don't return something like "SAP\jakobmoellers" but only return the username, e.g. "jakobmoellers".


• Also, make sure that the response contains the following attribute-statements
  
  
  
  • first_name
  
  
  • last_name
  
  
  • mail
  
  
  
  


• ... And make sure that the spelling of the attributes is exactly like I described it here!

For your convenience, I attached my SAML response from ADFS which my SAP CP Cockpit understands (of course, I removed the exact URLs and Signatures…). I advise you to match yours to the example:

<Response 

    xmlns="urn:oasis:names:tc:SAML:2.0:protocol" 

    xmlns:ns2="urn:oasis:names:tc:SAML:2.0:assertion" 

    xmlns:ns3="http://www.w3.org/2000/09/xmldsig#" 

    xmlns:ns4="http://www.w3.org/2001/04/xmlenc#" 

    Destination="YOUR SAP CP COCKPIT URL" 

    ID="RES-SSO-1e50e974-bed3-43ce-b505-0af91a9b8fcf" 

    InResponseTo="S7df73f00-9b60-430d-8a2a-20c96815029c-ffp.p2O05VX1cPIRRtXA7gq3wSxLvyPavG.PWD0h.KI" 

    IssueInstant="2017-03-10T11:41:18.809Z" 

    Version="2.0">

    <ns2:Issuer>YOUR SCI TENANT URL</ns2:Issuer>

    <Status>

        <StatusCode 

            Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>

    </Status>

    <Assertion 

        xmlns="urn:oasis:names:tc:SAML:2.0:assertion" 

        xmlns:ns2="http://www.w3.org/2000/09/xmldsig#" 

        xmlns:ns3="http://www.w3.org/2001/04/xmlenc#" 

        ID="A-d3a7a2f0-62bf-4dbb-a119-b399a1245666" 

        IssueInstant="2017-03-10T11:41:18.809Z" 

        Version="2.0">

        <Issuer>YOUR SCI TENANT URL</Issuer>

        <ds:Signature 

            xmlns:ds="http://www.w3.org/2000/09/xmldsig#">

            <ds:SignedInfo>

                <ds:CanonicalizationMethod 

                    Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>

                <ds:SignatureMethod 

                    Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>

                <ds:Reference 

                    URI="#A-d3a7a2f0-62bf-4dbb-a119-b399a1245666">

                    <ds:Transforms>

                        <ds:Transform 

                            Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>

                        <ds:Transform 

                            Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>

                    </ds:Transforms>

                    <ds:DigestMethod 

                        Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>

                    <ds:DigestValue>vcOG+BJ6hw7HuNt0BLQZC+

                        JertQ=

                    </ds:DigestValue>

                </ds:Reference>

            </ds:SignedInfo>

            <ds:SignatureValue>SOME SIGNATURE

            </ds:SignatureValue>

            <ds:KeyInfo>

                <ds:X509Data>

                    <ds:X509Certificate>SOME CERTIFICATE

                    </ds:X509Certificate>

                </ds:X509Data>

                <ds:KeyValue>

                    <ds:RSAKeyValue>

                        <ds:Modulus>SOME MORE SIGNATURES

                        </ds:Modulus>

                        <ds:Exponent>AQAB</ds:Exponent>

                    </ds:RSAKeyValue>

                </ds:KeyValue>

            </ds:KeyInfo>

        </ds:Signature>

        <Subject>

            <NameID 

                Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified">YOUR USERNAME WITHOUT DOMAIN

            </NameID>

            <SubjectConfirmation 

                Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">

                <SubjectConfirmationData 

                    InResponseTo="S7df73f00-9b60-430d-8a2a-20c96815029c-ffp.p2O05VX1cPIRRtXA7gq3wSxLvyPavG.PWD0h.KI" 

                    NotOnOrAfter="2017-03-10T11:51:18.809Z" 

                    Recipient="YOUR CLOUD COCKPIT URL"/>

            </SubjectConfirmation>

        </Subject>

        <Conditions 

            NotBefore="2017-03-10T11:36:18.809Z" 

            NotOnOrAfter="2017-03-10T11:51:18.809Z">

            <AudienceRestriction>

                <Audience>YOUR SAP CP SUB-ACCOUNT ID</Audience>

            </AudienceRestriction>

        </Conditions>

        <AuthnStatement 

            AuthnInstant="2017-03-10T11:41:18.809Z" 

            SessionIndex="S-SP-5659273a-d73a-4bf5-9552-65f4446c63d6" 

            SessionNotOnOrAfter="2017-03-10T23:41:18.809Z">

            <AuthnContext>

                <AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:PreviousSession</AuthnContextClassRef>

                <AuthenticatingAuthority>YOUR ADFS ENDPOINT URL</AuthenticatingAuthority>

            </AuthnContext>

        </AuthnStatement>

        <AttributeStatement>

            <Attribute 

                Name="mail">

                <AttributeValue 

                    xmlns:xs="http://www.w3.org/2001/XMLSchema" 

                    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 

                    xsi:type="xs:string">YOUR MAIL ADDRESS

                </AttributeValue>

            </Attribute>

            <Attribute 

                Name="first_name">

                <AttributeValue 

                    xmlns:xs="http://www.w3.org/2001/XMLSchema" 

                    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 

                    xsi:type="xs:string">Jakob

                </AttributeValue>

            </Attribute>

            <Attribute 

                Name="last_name">

                <AttributeValue 

                    xmlns:xs="http://www.w3.org/2001/XMLSchema" 

                    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 

                    xsi:type="xs:string">Moellers

                </AttributeValue>

            </Attribute>

        </AttributeStatement>

    </Assertion>

</Response>

Probably, you'll need some trial and error here but once you match the SAML response that SCI normally gives you without the separate corporate identity provider configuration to the SAML response of your ADFS, you should be able to open the Cloud Cockpit.

Another word of caution: as the Platform Identity Provider configuration is still beta functionality, you might still encounter bugs. If you have any problems or think you found a bug in the software, feel free to contact me here in the comments or raise the issue to SAP directly. As this blog article is not going into details with all the configuration steps and is therefore targeted at readers who are advanced in topics like user management and SAML, don't be afraid to ask also basic questions in case you could not follow. It was just my intention to describe a concept here rather than providing a step-by-step manual.

In the end, I hope that this article is of use to you and helps you to manage your SAP CP Members more efficiently, to become more compliant with your internal user management regulations concerning your Member management, and to increase your user/developer/admin experience by offering SSO to Members. Also, with this approach, the trust configuration between ADFS and SCI has to be done only once and can be reused for all SAP CP Sub-Accounts. You'll always create a new application in SCI, of course, but the trust between SCI and ADFS remains unchanged!

Cheers and happy SAML provisioning to all of you!

[agundala]

Hi Jakob,

Great blog series!

Question - Can we use an external IDP(which is already connected to an AD) instead of SCI to authenticate platform members?

Thanks!

Abi

[JakobMoellers]

Hi Abi,

at the moment, only SCI can directly be used as IdP for members (or, as I describe in this article, it can serve as a proxy to ADFS or arbitrary SAML IdPs). So if your external IdP uses SAML and is reachable from the users' browsers, you should be able to use it with the method I describe in this article. However, please consider that today, the functionality is only available as a beta-feature.

Kind regards,

Jakob

[Former Member]

Hi Jacob,

I am developing some SF extension and using HANA DBaaS to store Data and use SF OData API. I created the HTML5 application which is running on portal services.

Can we use the subaccount for connecting 3 SF instance to the same HCP global account? Now we have to move it to QA and Prod. Please let me know.

Regards,

Ravi Shankar.