How to disable the uniqueness of user email addresses in SAP IAS and BTP subaccounts (SAPCF)

[NabiZamani]

1. Motivation

When dealing with different environments, systems, services, and applications, you may run into some challenges related to the unique identifiers of your users. Here is a commons case:

Let's asume you have an AS ABAP system containing all your users and their authorizations. You wanna make sure that based on that, users can access your apps in your SAPCF subaccounts. A common solution is to use the SAP Identity Provisioning (Service) for reading the users and their authorizations ("roles") from your ABAP system and "syncing" them with your custom IAS tenant. In other words, the IPS will create/update users in your IAS tenant by reading them from ABAP. When the users access your FLP they will have to logon via your custom IAS tenant. You can configure your subaccount to create so called shadow users upon the very first access to apps on your subaccount. Basically, this setting is automatically creating a user in your subaccount's user store (XSUAA) after a successful authentication (and on first time access to one of your apps). Alternatively, you could disable the shadow user creation, but in that case you would have to manage the user creation upfront before their first access (typically using IPS to not only write the same source to IAS but also to your subaccount). In both options, you'll have the following problems:

1. In your ABAP system, email addresses are not unique


2. But when writing the users to IAS and SAPCF, email addresses must be unique

Because of that, the following may fail in case one or more users share the same email address in your ABAP user store (SU01):

1. Your IPS runs into an error because the IAS rejects the creation of a certain user caused by a unique email address violation. In other words, there is already a user in your IAS who already uses the same email address that shall be used by a new user. Of course, a manual creation of such a user in IAS will also fail.


2. Your SAPCF subaccount will also reject the creation of new users (be it manually or via shadow user) because of the same reason: the new user has en email address that is already in use in your subaccount.

 

What you will learn

In this little blog you'll learn how to disable the uniqueness of email addresses in both IAS and in your SAPCF subaccounts. After following the steps described below, you can create users in IAS and in SAPCF subaccounts that share the same email addresses. Your IPS/IAS will not run into errors because users in your ABAP system share the same email address. The shadow user creation will also not be blocked anymore due email addresses that are already in use.

Out of scope

We won't discuss the configuration of IPS here, please refer to other blogs. Same about IAS configuration. But in short, you may wanna fill the Login Name of your IAS with the User ID of your ABAP systems (IPS), then also set the IAS Login Name in your IAS applications as the Subject Name Identifier. This also makes sure that your IAS Login Name (filled from the ABAP User ID) is also used for your Principal Propagation to ABAP.

 

2. Basics and examples about Unique Identifiers (UIDs)

As the name already suggests, the unique identifier (UID) identifies a user uniquely. Very often, the UID is simply referred to as User ID. However, there can be multiple UIDs available. When comparing applications to each other, you may have recognized that many applications interpret and implement the unique identifiers of their users differently. For some, the only UID is the email address, for others it's some kind of User ID (i.e. your S/P user in the SAP world), and again for others both email and User ID are UIDs (usually independently). What all UIDs have in common is that they must be unique in the corresponding environment/application. In your SAPCF subaccount, they must be unique in the context of the configured/used Identity Provider(s).

Examples:

• AS ABAP
  Users in an ABAP system have a User ID identifying them (12 chars). However, their addresses can be shared among multiple users. Theoretically, every single user in an ABAP system could have the exact same email address, while a single User ID is allowed to exist once.


• SAP IAS
  SAP Identity Authentication (Service) has some configuration options. Out of the box, users can logon for example using a so-called Login Name, or they can use their email address. With the IAS default configuration, this also means the mentioned two UIDs must be unique in a certain IAS tenant, else IAS couldn't identify users uniquely and thus you couldn't use them for login.
  


• SAP BTP Subaccount (NEO)
  The old and meanwhile deprecated NEO environment uses classical User IDs in NEO subaccounts for identifying users. Email addresses can be shared among different users (similar to AS ABAP, see above).


• SAP BTP Subaccount (SAPCF)
  In SAPCF, per default the UID is the user's email address. That's why email addresses must be unique in SAPCF subaccounts per default.

 

3. Disable email address uniqueness in SAP IAS

In your IAS administration console

1. go to Logon Alias under Application & Resources / Tenant Settings


2. For the E-Mail
   
   
   
   1. turn off Allow Login 
   
   
   2. uncheck the column Unique
   
   
   
   

You're done (compare to the screenshot below). From now on, users in your IAS tenant can share the same email addresses.

Hint:

What happens if some time later you want to allow login via E-Mail? Simply check Unique and afterwards turn on Allow Login. Please note the information displayed/implemented currently:

Identity Authentication ensures the uniqueness only of the newly set values of the attributes. The system does not guarantee the uniqueness of the existing attributes.

 

 

Reminder

This is now the right time to check your configured Subject Name Identifier for the corresponding application in your IAS tenant. You may wanna set the IAS Login Name in your IAS applications as the Subject Name Identifier.

 

3. Disable email address uniqueness in SAPCF subaccounts

This is a little more complicated, but it can be done within minutes per subaccount. Please make sure you have the latest CloudFoundry CLI installed. Also make sure you are a subaccount admin to avoid authorization issues. In your subaccount, I assume you have your Cloud Foundry environment enabled, and you have already setup at least one cf space.

Choose your preferred REST client, i.e. Postman or Insomnia. The free versions of both are just fine for what we need. I'm using Insomnia for this blog. You will any your preferred REST client to call the XSUAA APIs.

 

3.1 Prepare API access to XSUAA

First of all, we need to create create an xsuaa instance with plan apiaccess. This allows you to access the xsuaa service APIs. For details please see the official SAP Help: Access SAP Authorization and Trust Management Service APIs. Execute the following CLI commands in your:

#login to your SAPCF org and space in once command (replace email, org, space and cf api/landscape)

cf login -a https://api.cf.eu10-004.hana.ondemand.com -u my.email@gmail.com -o myorg -s myspace



#create an xsuaa instance with plan apiaccess

cf create-service xsuaa apiaccess admin-xsuaa-apiaccess

#create a key

cf create-service-key admin-xsuaa-apiaccess admin-key

#print the created key

cf service-key admin-xsuaa-apiaccess admin-key

 

The last command will print out something similar to this here (don't share yours publicly!):

 

{

  "credentials": {

    "apiurl": "https://api.authentication.eu10.hana.ondemand.com",

    "clientid": "sb-****",

    "clientsecret": "123****=",

    "credential-type": "binding-secret",

    "identityzone": "my-subdomain",

    "identityzoneid": "***",

    "sburl": "https://internal-xsuaa.authentication.eu10.hana.ondemand.com",

    "subaccountid": "***",

    "tenantid": "***",

    "tenantmode": "dedicated",

    "uaadomain": "authentication.eu10.hana.ondemand.com",

    "url": "https://my-subdomain.authentication.eu10.hana.ondemand.com",

    "verificationkey": "-----BEGIN PUBLIC KEY-----\n***\n-----END PUBLIC KEY-----",

    "xsappname": "***",

    "zoneid": "***"

  }

}

 

The important properties for us are:

• apiurl: the base url for the API, which will be extended by certain API paths


• clientid: similar to a user id, or probably better to be called a "technical user"


• clientsecret: like a password


• url: based on this you can construct the OAuth2TokenServiceURL by simply appending /oauth/token

We will use the properties in the next step for our REST client when calling the xsuaa APIs.

Hint:

Even if your SAPCF environment runs in an extension landscape like eu10-004 (like in my example above, see cf login above), the properties in your service key at the time of writing this blog point to the main landscape without the extension (i.e. eu10 instead of eu10-004).

 

3.2 Call XSUAA REST API to disable email address uniqueness

Here comes now the fun part: Making some easy REST calls.

If you are interested in the relevant documentation read here:

• https://api.sap.com/api/SecuritySettingsAPI/overview


• https://api.sap.com/api/SecuritySettingsAPI/path/readSettings


• https://api.sap.com/api/SecuritySettingsAPI/resource


• Access SAP Authorization and Trust Management Service APIs

All we want to achieve is setting treatUsersWithSameEmailAsSameUser = false. The payload we want to send is as simple as this:

{

  "treatUsersWithSameEmailAsSameUser": false

}

This flag/feature was introduced in February 2022. The documentation for this property currently tells (see TenantSettingsReq😞

Set to false to disable the fallback at logon that if the logon ID provided in the token by the identity provider is unknown, the service attempts to log on the user with the e-mail address from the token. When false, the service attempts to create a missing user if user creation at logon is allowed. Note that before you can switch this parameter from false to true again, ensure that e-mail addresses are unique among your shadow users.

Or simply said: The value of treatUsersWithSameEmailAsSameUser defaults to true, means email addresses must be unique (within each configured IdP). Cannot be set to true if users with duplicate email addresses exist (these must be removed first).

Now let's configure our REST client, in my case Insomnia (the boiled values are derived from the service key which we created in the previous step above):

• HTTP Method: PATCH


• URL: <apiurl from service key>/sap/rest/authorization/v2/securitySettings (example: https://api.authentication.eu10.hana.ondemand.com/sap/rest/authorization/v2/securitySettings)


• JSON Payload: see JSON code block above


• OAuth 2 configuration
  
  
  
  • Enabled: checked
  
  
  • Grant Type: Client Credentials
  
  
  • Access Token URL: <url from service key>/oauth/token (example: https://my-subdomain.authentication.eu10.hana.ondemand.com/oauth/token)
  
  
  • Client ID: <clientid from service key>
  
  
  • Client Secret: <clientsecret from service key>
  
  
  
  


• HEADERS
  
  
  
  • Accept: application/json
  
  
  • Content-Type: application/json
  
  
  
  

 

After sending the request, your subaccount accepts shared email addresses for all configured Identity Providers in your subaccounts (currently not possible for selective IdPs).

 

Hint: 

Before sending the PATCH call you could make a GET call on the same API to see the current settings. The property treatUsersWithSameEmailAsSameUser will be included in the response, but it will show up after after you've sent the PATCH call. Try it yourself.

 

 

The response contains the property treatUsersWithSameEmailAsSameUser set to false (usually at the very bottom):

{

	...

	"treatUsersWithSameEmailAsSameUser": false

}