Skip to Content
Technical Articles
Author's profile photo Sophia Yang

How to configure SSO Mechanism in Mobile Connectivity Ⅰ

From Mobile Service in Cloud Foundry to Apps in Cloud Foundry

In this scenario, both Mobile Service and Back-end service deployed in Cloud Foundry.There are four types of “SSO Mechanism” apply to this kind of deployment:

  • Forward Authentication
    • Back-end Service uses the same XSUAA instance with mobile application
    • Back-end Service grants scopes access to Mobile Application
  • OAuth2 User Token Exchange
  • OAuth2 SAML Bearer Assertion
  • OAuth2 Client Credentials

Prerequisite

  • Create Mobile Application

    • Create a Mobile Application called “mobileApp” with the default XSUAA service instance in Cloud Platform Mobile Services Cockpit. By default, system will create a new XSUAA service instance with the prefix of application name “mobileApp” and “-xsuaa” as the suffix, which name is ” mobileApp-xsuaa”.

    • The “Mobile Connectivity” feature must be assigned. 

    • Check the XSUAA service instance in SAP Cloud Platform Cockpit.
      Navigate to {Your Global Account} > {Your Sub-account} > {Your Space} > Services > Service Instances page, there is a “mobileApp-xsuaa” XSUAA service instance created for “mobileApp” as following: 

  • Deploy Back-end service

    • Here deployed a sample odata service “odata-service-backend” in the same space with “mobileApp”. 

Forward Authentication

  • Back-end Service uses the same XSUAA instance with mobile application

    In this scenario, as they used the same XSUAA instance, the User Token is effective for both sides, Mobile Connectivity just forward the User Token to Back-end Service directly.

    • Step 1: Binding XSUAA service instance
      • One way is “odata-service-backend” binding the same XSUAA service instance with “mobileApp”.

        In SAP Cloud Platform Cockpit, navigate to {Your Global Account} > {Your Sub-account} > {Your Space} > Applications > odata-service-backend > Service Bindings page, click the “Bind Service” button, in the popup window, choose “Authorization & Trust Management”, select the existing XSUAA service “mobileApp-xsuaa” as the Back-end Service’s XSUAA service instance.

      • The other way is “mobileApp” binding the same XSUAA service with “odata-service-backend”.

        When creating the Mobile Application, in the “XSUAA Service” field, select the XSUAA service instance you created both for “odata-service-backend” and “mobileApp”.

    • Step 2: Create destination
      • In Cloud Platform Mobile Services Cockpit, navigate to Mobile Applications > Native/Hybrid page, select the “mobileApp” just created, click the “Mobile Connectivity” feature to create a new Destination.
        • URL: Input odata-service-backend’s url.
        • SSO Mechanism: Forward Authorization. Notice: If Mobile Service connects to AppRouter instead of Back-end Service, the steps are the same, but should check the “Forward to AppRouter” checkbox.

Forward Authentication

  • Back-end Service grants scopes access to Mobile Application

    If Back-end Service and Mobile Service used different XSUAA service instances, through granting scopes access to Mobile Application, destination can still use Forward Authorization.

    This scenario applies to Mobile Service and Back-end Service deployed in different spaces, sub-accounts, even different global accounts.

    • Step 1: Create XSUAA Service instance for Back-end Service
      • In SAP Cloud Platform Cockpit, navigate to {Your Global Account} > {Your Sub-account} > {Your Space} > Applications > odata-service-backend > Service Bindings page, click the “Bind Service” button, select the “Authorization & Trust Management” Service Type, choose “application” Plan.
      • Prepare xs-security.json file as following:
                {   
                    "xsappname": "xsuaa-forward",
                    "tenant-mode": "shared",
                    "scopes":
                    [
                        {
                            "description": "Service user scope",
                            "name": "$XSAPPNAME.Everyone",
                            "granted-apps": [ "$XSAPPNAME(application, 88*****0e, mobileApp-*g)"]
                        },
                        {
                            "description": "Service administrator scope",
                            "name": "$XSAPPNAME.ViewMetrics",
                            "granted-apps": [ "$XSAPPNAME(application, 88*****0e, mobileApp-*g)"]
                        }
                    ],
                    "role-templates":
                    [
                        {
                            "description": "Service user role",
                            "name": "Everyone",
                            "scope-references": ["$XSAPPNAME.Everyone"]
                        },
                        {
                            "description": "Service administrator role",
                            "name": "ViewMetrics",
                            "scope-references": ["$XSAPPNAME.ViewMetrics"]
                        }
                    ]
                }​
      • Click the “Browse” button to upload the prepared xs-security.json file.
        • This “xsuaa-forward” xsappname will be used in step 2.

        • The “tenant-mode” should be set the same value with mobileApp’s XSUAA service instance’s “tenant-mode”.

        • The scope name is “$XSAPPNAME.Everyone”, it will be referenced in step 2.

        • Add “granted-apps” property to “scopes”. The format is:

          $XSAPPNAME(application, {The Sub-account id of Mobile Service deployed}, {The xsappname of  Mobile Service's XSUAA service instance}).
        • The xsappname of mobileApp’s XSUAA service instance gets from {Global Account} > {Sub-account} > {Space} > Services > Service Instance page, select the “mobileApp-xsuaa”, on the “Service Keys” part in the right, click the more icon, then click the “View” button as following: It will pop up XSUAA detail information: We can see the “xsappname” value is “mobileApp-*g!t57”, remove “!t57” just use “mobileApp-*g”.

    • Step 2: Update xs-security.json of Mobile Service’s XSUAA service instance
      • Prepare the xs-security.json file as following:
            {
                "xsappname":"mobileApp-*g",
                "role-templates":[
                    {
                        "name":"ODataViewer",
                        "description":"View Data",
                        "scope-references":[
                            "$XSAPPNAME(application, 88*****0e, xsuaa-forward).Everyone", "$XSAPPNAME(application, 88*****0e, xsuaa-forward).ViewMetrics"
                        ]
                    }
                ],
                "role-collections":[
                    {
                        "name":"ODataViewer",
                        "description":"Viewer ODataService data",
                        "role-template-references":[ 
                            "$XSAPPNAME.ODataViewer"
                        ]
                    }
                ],
                "foreign-scope-references": [ "$ACCEPT_GRANTED_SCOPES"]
            }​
      • “mobileApp-*g” is the xsappname of mobileApp’s XSUAA service instance. Please refer step 1 on how getting the value.
      • Create a “role-template” named “ODataViewer”, it references the scopes we defined in step 1. The format is:
         $XSAPPNAME(application, {The Sub-account id of XSUAA service instance created in step 1}, {The xsappname of XSUAA service instance created in step 1}).{The scope name of XSUAA service instance created in step 1} ​
      • Add a new role-collection named “ODataViewer”.
      • Add “foreign-scope-references” property.
      • In Cloud Platform Mobile Services Cockpit, update the xs-security.json file in Mobile Applications > Native/Hybrid > mobileApp page , click “Security” tab. In “Role Settings” part, click the “Edit” button: It will pop up window, click the “Browse” to upload the xs-security.json file just prepared:
    • Step 3: Create destination

      The procedure is the same with Back-end Service uses the same XSUAA instance with mobile application Create a Destination part.

    • Step 4:Assign customers the “ODataViewer” role collection
      • In SAP Cloud Platform Cockpit, navigate to {Your Global Account} > {Your Sub-account} > Security > Role Collections page, here we can see the role collection “ODataViewer” we just created: Click the “>” icon in the right, go “ODataViewer” detail page: Click “Edit” button, in the User part, enter the ID, Identity Provider and E-Mail.
      • After assigning the new role, users need to re-login to make the role take effect.

OAuth2 User Token Exchange

If Back-end Server and Mobile Service used different XSUAA service instances under the same sub-account, you can use “User Token Exchange” SSO Mechanism.

  • Step 1:Prepare xs-security.json file

    In order to support this kind of authorization, the Back-end XSUAA service instance needs to support “urn:ietf:params:oauth:grant-type:jwt-bearer” grant type. Prepare the xs-security.json file like following:

        {
            "xsappname": "xsuaa-token-exchange",
            "tenant-mode": "shared",
            "oauth2-configuration": {
                "grant-types": [
                  "urn:ietf:params:oauth:grant-type:jwt-bearer"
                ]
            },
            "role-templates":
            [
                ......
            ],
            "scopes":
            [
                ......
            ]
        }​
  • Step 2: Create XSUAA Service instance for Back-end Service

    In SAP Cloud Platform Cockpit, navigate to {Your Global Account} > {Your Sub-account} > {Your Space} > Applications > odata-service-backend > Service Bindings page, click the “Bind Service” button, select the “Authorization & Trust Management” Service Type, choose “application” Plan, and upload the prepared the xs-security.json file.

  • Step 3: Get the detail information of Back-end’s XSUAA service instance.

    In SAP Cloud Platform Cockpit, navigate to {Your Global Account} > {Your Sub-account} > {Your Space} > Applications > odata-service-backend > Service Bindings page, click the “Show sensitive data” button: 
    It will show the XSUAA service instance detail information as following: 
    The “url”, “clientid”, “clientsecret” properties will be used in step 3.

  • Step 4: Create destination
    • In Cloud Platform Mobile Services Cockpit, navigate to Mobile Applications > Native/Hybrid > mobileApp page, click the “Mobile Connectivity” feature to create a new Destination. Set “SSO Mechanism” to “OAuth2 User Token Exchange”. Depending on the tenant modes of Mobile Service and Back-end Service, there are two scenarios:
      • If Mobile Service and Back-end Service are single-tenant modes: 
        • Token Service URL: Set to the “url” property got in step 2, then append “/oauth/token”
        • Token Service URL Type: Dedicated.
      • If Mobile Service and Back-end Service are multi-tenant modes:
        • Token Service URL: Set to “https://authentication.****.com/oauth/token”, remove the tenant part in the “url” property got step 2, and append “/oauth/token”.
        • Token Service URL Type: Common.
    • Client ID: The “clientid” value got in step 2.
    • Client Secret: The “clientsecret” got step 2.

OAuth2 SAML Bearer Assertion

This scenario applies to Mobile service and Back-end Service deployed in different spaces, sub-accounts, global accounts, even cross different systems.

  • Step 1: Get the “SAML Metadata” file of the sub-account where the Back-end service instance deployed
    In SAP Cloud Platform Cockpit, navigate to {Your Global Account} > {Your Sub-account} > Security > Trust Configuration page, click the “SAML Metadata” button to download it.
  • Step 2: Create destination

    In Cloud Platform Mobile Services Cockpit, navigate to Mobile Applications > Native/Hybrid > mobileApp page, click the “Mobile Connectivity” feature to create a new Destination: 

    • SSO Mechanism: OAuth2 SAML Bearer Assertion

    • Audience: In the SAML Metadata file got in step 1, copy the value of “entityID”.

    • Token Service URL: In the SAML Metadata file got in step 1, find the xml node pattern as following:

      <md:AssertionConsumerService Location="{Token Service URL}" Binding="urn:oasis:names:tc:SAML:2.0:bindings:URI" index="1"/>

      Copy the value of Location property.

    • Token Service URL Type: Dedicated.

    • Client Key: The “clientid” value of Back-end’s XSUAA service instance.

    • Client Secret: The “clientsecret” value of Back-end’s XSUAA service instance.

    • SAML Assertion Issuer: Name a issuer.

    • Signing Key: You can click the “Generate Key” to generate one.

  • Step 3: Download the “SAML Metadata” file generated by this destination in its detail page
  • Step 4: Upload the “SAML Metadata” file to the Back-end Service’s sub-account

    In SAP Cloud Platform Cockpit, navigate to {Your Global Account} > {Your Sub-account} > Security > Trust Configuration page: Click the “New Trust Configuration” button, in the popup window, click the “Upload” button, upload the “SAML Metadata” file download in step 3. Give this trust configuration a name

OAuth2 Client Credentials

This scenario is suitable for machine-to-machine authentication, for example in a cron job which preforms schedule task.

    • Step 1: Create XSUAA service instance for Back-end Service

      In order to support this kind of authorization, the Back-end XSUAA service instance needs to support “client_credentials” grant type. Prepare the xs-security.json file like following:

          {
              "xsappname": "client-credentials",
              "tenant-mode": "shared",
              "oauth2-configuration": {
                  "grant-types": [
                    "client_credentials"
                  ]
              },
              "role-templates":
              [
                  ......
              ],
              "scopes":
              [
                  ......
              ]
          }​
    • Step 2: Get the detail information of Back-end’s XSUAA service instance

      In SAP Cloud Platform Cockpit, navigate to {Your Global Account} > {Your Sub-account} > {Your Space} > Applications > odata-service-backend > Service Bindings page, click the “Show sensitive data” button. The “url”, “clientid”, “clientsecret” properties will be used in step 3.

  • Step 3: Create destination
    • In Cloud Platform Mobile Services Cockpit, navigate to Mobile Applications > Native/Hybrid > mobileApp page, click the “Mobile Connectivity” feature to create a new Destination. 
    • Token Service URL: Copy the “url” property got in step 2, then appends “/oauth/token”
    • Client ID: The “clientid” value got in step 2.
    • Client Secret: The “clientsecret” got step 2.

 

Conclusion

Depending on the way Mobile Service and Back-end Service deployed, you can choose the suitable SSO Mechanism, bellow are our recommendations:

  • Mobile Service and Back-end Service deployed in the same space or sub-account:
    • OAuth2 User Token Exchange (Recommended, easy to configure)
    • Forward Authentication.(Mobile Service and Back-end Service used same XSUAA service instance)
  • Mobile Service and Back-end Service deployed in different spaces, sub-accounts, even different global accounts:
    • Forward Authentication.(Back-end Service grants scopes access to Mobile Application)
    • OAuth2 SAML Bearer Assertion
  • Mobile Service and Back-end Service deployed in different systems:
    • OAuth2 SAML Bearer Assertion

Assigned tags

      5 Comments
      You must be Logged on to comment or reply to a post.
      Author's profile photo Rajkumar Shanmuganathan
      Rajkumar Shanmuganathan

      Excellent blog Sophia Yang ! We are currently moving from NEO to Cloud foundry SCPms and your blog has undoubtedly enlightened me. Just a question, what type of authentication has to be used in in SCms destination in order to consume the OData from on-premise system via cloud connector directly?Any best practices or your recommendations?

      Thanks - Raj.

      Author's profile photo Sophia Yang
      Sophia Yang
      Blog Post Author

      Dear Rajkumar,

      Sorry for the delay reply, you can choose the "Cloud Connector SSO" as the

      Author's profile photo Martin Frick
      Martin Frick

      Thanks for this amazing overview Sophia Yang ! I've tried to understand the different options for hours now, until I found your blog! This is the perfect overview!

      Author's profile photo Greg Carino
      Greg Carino

      Very informative. Thank you!

      Regarding OAuth2SAMLBearerAssertion (2 different CF subaccounts), what does the SAML issuer value specifically refer to?

      • SAML Assertion Issuer: Name a issuer.

      Regards,

      Greg

      Author's profile photo Sophia Yang
      Sophia Yang
      Blog Post Author

      Hi Greg,

      Thanks for your question. For the "SAML Assertion Issuer" field, you can just give the issuer a name you like, there's no restriction or reference. Thanks.