Managing technical users for BTP platform access

[pieterjanssens]

Intro

Using a technical user for accessing SAP Business Technology Platform is often hinted at in SAP Help or community tutorials, but how exactly this can be achieved, has not been documented as far as I can tell. I'm writing this blog to share the lessons learned and to teach you how you can manage your technical users for SAP BTP going forward.

A technical user is a user account that is used for automated and integrated operations.

If you arrive at the situation where you want or need to use a technical user for accessing SAP BTP and you start searching for information, you might arrive at this SAP Support page: Online help: Technical communication users. Unfortunately, this isn't the solution you are looking for. These technical communication users are not known to the SAP ID Services identity provider (the default SAP BTP IdP) and hence cannot be used to authenticate such a technical communication user.

ℹ️ An S-user account (which depends on manually extending its validity) is meant to be associated with a person and should not be used as a technical user.

Trust IAS

The solution can be found in SAP Cloud Identity Services - Identity Authentication (IAS). On a global account (platform) level, a trust can be setup with a single IAS instance. This is not only be useful to strengthen the security to access your BTP environment (e.g. stronger password policies and MFA enforcement), but also offers a solution for managing technical users.

It's important to note the difference between platform access and application access. The population of the users accessing either the platform or the applications can be vastly different. It can be a good option to use a separate IAS productive instance dedicated to platform access.

ℹ️ If it concerns a CPEA global account, you can create additional tenants via self-service. I can confirm that you can select an 'additional' type IAS tenant in the BTP platform trust configuration.

Setup in a nutshell

Prerequisite: an IAS instance associated to the same SAP customer account as the SAP BTP global account. Ideally, this should be a productive IAS instance.

1. Establish platform trust with IAS

1. In BTP the global account, access the "Trust Configuration" page within the "Security" panel of the side menu.


2. Click "Establish Trust" and select the IAS instance, confirm


3. Important: Note down the "Origin Key" (hereafter referred to as '<origin-key>')

2. Create technical user(s)

1. Login to IAS as admin


2. add one or more technical users manually
   
   
   
   • Set an initial password and logon once with each to set a definitive password
   
   
   • The email does not to exist. I chose to align my login name and email. E.g. login name: "tech-btp-cfapi" & email: tech-btp-cfapi@company.com
   
   
   • Mark email as verified
   
   
   
   

3. Authorize the technical users

On subaccount level, the user needs to be a member (with certain roles) for doing operations on subaccount level (e.g. BTP API).

1. Access the subaccount


2. Go to the 'Users' page on the 'Security' panel of the side menu


3. Click 'Create'


4. Enter the (dummy) email address of the technical user for both login name and email


5. Important: select the IAS instance as Identity Provider

Cloud Foundry org and space level. This is required for the CF API.

1. Within your subaccount, access your Cloud Foundry space


2. Navigate to the 'members' page


3. Click 'Add Members'


4. Enter the (dummy) email address of the technical user


5. Important: select the IAS instance from the 'origin' selection


6. Assign role "Space Developer" if necessary - e.g. to manage apps


7. Optionally, assign a specific Org Manager/Org Auditor role on org level if required for your integration

Use case #1 - CF CLI for CI/CD

I'm using this in an Azure DevOps CI/CD flow to deploy apps upon release to SAP BTP Cloud Foundry.

To log in with the technical user from IAS, login with a specific 'origin':

cf login --origin <origin-key>

Use case #2 - CF API destination for MTX

In multi-tenant implementations, CF routes can be automatically created and deleted upon subscribing and unsubscribing to and from applications. To achieve this, the CF API is used by the service implementation of the provider application. The destination that is used to store the credentials to the CF API, can be used by any application, and therefore I opted to manually set it up on subaccount level.

ℹ️ You need at least a destination service instance on space level to be able to access the destination on subaccount level, even if the space level destination service does not contain any own destinations.

I have created a minimal example to demonstrate using the CF API from a backend service deployed to SAP BTP Cloud Foundry: https://github.com/piejanssens/btp-cf-api-destination

1. Clone the GitHub repository


2. Test the OAuth2Password grant to get an access token from UAA (via IAS)
   Prerequisite: this assumes having the REST Client extension in BAS / VS Code
   
   
   
   1. Open the 'prep' folder
   
   
   2. Create a '.env' file with the following tuples:
      Note: if you have a '+' character in your username, you will need to URL encode it (in the .env, not in the actual destination)
      
      
      

      cf_login=https://login.cf.<region>.hana.ondemand.com
      
      cf_api=https://api.cf.<region>.hana.ondemand.com
      
      idp_origin_key=<origin-key>
      
      idp_username=<tech-user-username>
      
      idp_password=<tech-user-password>

      
      
   
   
   3. Run the first request from test.http --> should show the response with access token
   
   
   4. Run the second request from test.http --> should show the CF spaces info
   
   
   
   


3. Go to your subaccount


4. Import the 'CFAPI' destination from the 'prep' folder
   
   
   
   1. Change the username, password
   
   
   2. Make sure you have the correct region in the subdomain of both the API and the token service  URL
   
   
   3. Important: Make sure to change the origin value with the <origin-key> at the end of the token service URL
   
   
   4. Set a dummy client secret (bug in BTP cockpit...)
   
   
   5. Save
   
   
   6. Edit again
   
   
   7. Remove the value of the client secret input field
   
   
   8. Save
   
   
   
   


5. From your terminal in the root project folder
   
   
   
   1. Run 'mbt build'
   
   
   2. Make sure you are logged in (cf login) and targeting the correct org/space
   
   
   3. Run 'cf deploy mta_archives/cfapi_0.0.1.mtar'
   
   
   4. Access the '-app' URL once it's completely deployed
   
   
   
   

The resulting page should show the CF space information which is obtained by the backend service from the CF API via the 'CFAPI' destination.

ℹ️ You might have noticed that we now have set a client ID with value 'cf' and an empty client secret. This is intentional and required by CF's UAA implementation to get this OAuth grant type to work.

Use case #3 - SAP Integration Suite

Gotya, not going in to that because it's not a best practice use case (any longer). There is a better way: Creating Service Instance and Service Key for Inbound Authentication

Use case #4 - SAP BTP API

No specific examples from my own experience yet, but there are many possibilities for automating BTP administration tasks via the APIs of the SAP Cloud Management service for SAP BTP.

To get an OAuth access token using curl (any region):

curl https://login.cf.eu10.hana.ondemand.com/oauth/token \

-X POST \

-H 'Content-Type: application/x-www-form-urlencoded' \

--user "cf:" \

-d username=############## \

-d password=############## \

-d client_id=cf \

-d grant_type=password \

-d response_type=token \

-d login_hint=%7B%22origin%22:%22##############%22%7D

Conclusion

This blog has shown that (since the support for custom IdP on platform level), it is now possible to implement a manageable solution for technical users through the use of IAS. This allows to use dedicated user accounts only to be used by applications, systems, scripts and integrations that might have different password and access policies than true, human users.

 

🙏 Special thanks to gregorwolf for the help in troubleshooting the password grant on IAS.

[yannmiquel]

Thanks ! Can't wait to try the

cf login --origin

to avoid putting my (personal) credentials into the gitlab pipeline

[nicorunge]

Hi piejanssens,

you wrote: "It’s important to note the difference between platform access and application access."

Did you also figured out, how to set up a technical-user for your application? Currently, I see two options, but both do not lead to success.

• Set up a normal user in BTP via SAP ID Service and use it as technical-user. But as you already said: An S-user account (which depends on manually extending its validity) is meant to be associated with a person and should not be used as a technical user.


• Set up a technical user via SAP IAS, like you described in the blog. But when using the user to get access to my application, it led me to the following problem: 2766354. Probably because the SAP IAS is communicating via SAML protocol?! Also discussed here or here in the comments. How does your Trust Configuration for your SAP IAS look like? Is it setup as OIDC-Identity-Provider?

Or maybe you have another idea how to archive this?
As I'm thinking this in a Multitenant context, I also don't wont to provide the clientId and clientSecret to our customers, as gregorw also discussed here.

Thanks & Regards
Nico

 

 

 

[pieterjanssens]

Hi Nicolas,

This blog is specifically about dealing with platform access requirements.

Application access (subaccount level) should be more widely covered already.

I think it's best if you raise the question in Q & A and explain your use case elaborately.

Feel free to comment with a link to the question.

Best regards,

Pieter

 

 

[Fidudjan31]

Hi Pieter.

Thanks for this guide.

At step "Set an initial password and logon once with each to set a definitive password" I wonder how to proceed with a dummy mail as the password confirmation process though universal ID expect the user to asnwer a mail.

[pieterjanssens]

Hi Frederic,

 

The easiest way to do this is by visiting the IAS instance hostname in a new browser session (InPrivate/Incognito).

 

Best regards,

Pieter

[Marçal_Oliveras]

Hi piejanssens ,

Thanks for the blog, I'm trying to achieve what you described but not only for technical users, also for subaccount administrators that access the BTP cockpit.

From your blog I understand that I have to establish the trust to IAS in the Global Account. Is that correct? Why can't I just establish trust with a subaccount only?

Self-answered: The documentation makes it clear that trust for platform users needs to be established in the Global Account. After doing that, the Identity Provider for platform users is automatically available in all subaccounts.