Connect SAP Cloud Identity Authentication Service as a proxy to Okta using OpenID Connect

[harjeetjudge]

SAP Cloud Identity Services (IAS) allows integration with a corporate identity providers using OpenID Connect (OIDC) protocol.  This feature was originally only supported with Azure AD, but now other OIDC compliant identity providers are also supported.  In this blog I will showcase how we can setup Okta as a corporate IDP with SAP Cloud Identity Service using OIDC.  This blog is specific to OIDC setup, but we also support integration using SAML.  If you are interested in integrating SAP Cloud Identity Authentication Service with Okta using SAML, read this blog.

Create OpenID Connect application in Okta

Note, the Okta configuration below is based on the testing I've done, but it's best to work with your Okta admin and follow best practices recommended by Okta.

1. Access your Okta admin console.


2. Click Applications >> Create App Integration.


3. Choose OIDC - OpenID Connect for Sign-in method and Web Application as the Application Type.


4. Specify App integration name.  Authorization Code grant type should be enabled by default.


5. Specify the following:
   
   
   
   • Sign-in redirect URIs: https://<IAS tenant host>.accounts.ondemand.com/oauth2/callback
   
   
   • Sign-out redirect URIs: https://<IAS tenant host>.accounts.ondemand.com/oauth2/logout
   
   
   
   


6. Choose who should have access to the application.  In my case I chose to allow access to everyone in the organization.  Optionally, enable the Federation Broker Mode and Save your application.  In my setup I disabled this option.


7. Under the General tab of the created application, choose the Client authentication method.  By default client authentication is set to use Client secret, but Public key / Private key is also possible.  Use the Copy icons to make note of the Client ID and Client Secret as they will be required for setup in SAP Cloud Identity Authentication Service.    For now, I will use Client secret, but check the Q&A portion of the blog to see to how to use Public key/ Private key option.  See Okta documentation for recommendations on choosing the client authentication method.


8. Under the Sign On tab, navigate to the OpenID Connect ID Token section.  By default only the user attributes are included in the token, but there may be a requirement to have groups information included in the token as well.  For eg, users group information may be required to dynamically assign user to role collection in SAP Business Technology Platform.  Edit the configuration and set the Groups claim filter as shown in the screenshot to include all groups.


9. If necessary, under Assignments tab, choose the groups that should have access to the application.  Everyone group should be listed already, but this will depend upon how you decided to setup the application in step 6 above.


10. Click Security >> API from the left panel and select the default authorization server.


11. Make note of the Issuer URL. This will be required later SAP Cloud Identity Authentication Service setup.


12. Click Claims tab and ensure the claims shown below are included.  I've modified the default setup to issue the additional claims listed below.  Note that Groups, givenName and familyName are of ID token type.  These claims will come in handy later if we dynamically create the user in SAP Business Technology Platform or assign dynamic role collections.  Without the claims some of the fields in the user profile in SAP BTP won't get populated properly.  Ideally givenName and famillyName claims should be given_name and family_name respectively because that's what SAP BTP is expecting, but I couldn't get Okta to include those attributes in the ID token.  You will see later that I have to enrich these Okta claims in SAP Cloud Identity Authentication Service for use with SAP BTP.
    
    
    
    • email
    
    
    • givenName
    
    
    • familyName
    
    
    • Groups
    
    
    
    

Setup Okta as corporate identity provider in SAP Cloud Identity Authentication Service

1. Log into SAP Cloud Identity Authentication Service admin console.


2. Click Identity Provider >> Corporate Identity Providers.


3. Click the Create button and specify a Display Name.  Click Save.


4. Click Identity Provider Type and choose OpenID Connect Compliant.  Click Save.


5. Click OpenID Connect Configuration and specify a Discovery URL.  The Discovery URL is set the Issuer URL copied earlier Okta authorization server configuration.  Click the Load button.  Most fields on the page should get populated.


6. Paste the Client ID and Client Secret copied from Okta application earlier.


7. Under Scopes, click Add and add the email scope and click the Save icon.


8. Click Validate button.  Click OK on the popup message.  A new browser tab will open.


9. Specify credentials of Okta user who has access to the application created in Okta earlier.  The validation check should be successful.


10. Save the OpenID Connect Configuration.


11. Click Subject Name Identifier and change from None to Email.


12. Click Enrich Token Claims and set the claims as in the table below.  We exposed givenName and familyName in the Okta claim earlier, but this enrichment is required because SAP Business Technology Platform expects the name to be given_name and family _name.  Without this enrichment the user's first and last name will not get populated in the user profile in SAP BTP.
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    

    Claim	Value
    family_name	${familyName}
    given_name	${givenName}

    
    


13. Click Save.

Test the configuration.

For my setup I am using a SAP BTP subaccount that is already setup to trust SAP Cloud Identity Authentication Service.  Furthermore, the shadow user creation options is enabled in SAP BTP so that users are dynamically created.

1. Log into SAP Cloud Identity Authentication Service admin console.


2. Click Applications & Resources >> Applications.


3. Select the application associated with your BTP Subaccount and click Conditional Authentication.


4. Change the Default Identity Provider from Identity Authentication to Okta and click Save.


5. Access your BTP Subaccount and launch any existing application in a new browser session.  For my test, I used SAP Build Work Zone, standard edition, but any existing application that requires authentication through SAP Cloud Identity Authentication Service will suffice.


6. Choose your SAP Cloud Identity Authentication Service.  You should be redirected to Okta for authentication.


7. Confirm you are able to successfully authenticate to Okta.


8. Note that the user is create automatically in SAP BTP and has the user profile populated properly.


9. Optionally, configure the role collection mapping using the users group information from Okta.

How can I see the what claims are sent to SAP Cloud Identity Authentication Service by Okta in the token?

The best way to see the JWT token sent to IAS is by reviewing the troubleshooting logs in SAP Cloud Identity Authentication Service.

1. In you IAS admin console click Monitoring and Reporting >> Troubleshooting Logs.


2. Click Go to see the last hours logs.


3. Search for the word "token" to see the token sent by Okta to IAS or token issued by IAS to SAP BTP.


4. Click Log Details to see detailed log.  We can easily the see the various attributes received by IAS from Okta.

How can I use the Private Key as the client authentication method instead of using Client secret?

1. Edit the IAS application in Okta and switch Client Authentication method to Public key/Private key.


2. Select Use a URL to fetch keys dynamically.


3. Set the URL to https://<IAS tenant host>.accounts.ondemand.com/oauth2/certs and Save the changes.


4. Modify the OpenID Connection Configuration in SAP Cloud Identity Authentication Service and change the Client Authentication Method to Private key JWT.


5. Validate your updated configuration and Save.

Enjoy!

[dalmada]

Hi, we have this setup working for OKTA and SAP Cloud. How do we make this work for the SAPGUI?

 

THanks,

Daniel

[Former Member]

Hi, Is it possible to enforce SSO by way of your article?

I would like to restrict access to BTP to SSO only.

 

Thanks,

Moeka