Page tree
Skip to end of metadata
Go to start of metadata


The Purpose of this page is to clarify how SAML Single Sign-On (SSO) has been implemented in SAP Mobile Secure.


SAML SSO authentication has been introduced in SAP Mobile Secure offering another alternative to Cloud and Enterprise  authentication. We are going to discuss this integration in details.

Why implementing SAML SSO in SAP Mobile Secure?

SAP Mobile Secure supports SAML SSO. Its implementation allows Mobile Secure Admin user to log in using SAML authentication. It is a certificate based authentication / SSO for administrators of Mobile Secure Admin Portal whose credentials are provided by an enterprise identity provider (IdP). These administrators can bypass the login page of Mobile Secure and Mobile Place because of SAML authentication.

The benefits are clearly in the simplicity of the user experience and administration because it is not necessary to maintain different user credentials. Instead, the same certificate/enterprise credentials can be used to log into Mobile Secure and all other enterprise applications. Furthermore, the user administration is within the enterprise and when an employee leaves the company, he is not able to access Mobile Secure anymore.

How SAML SSO has been implemented?

Without SAM SSO, a user needs to enter three information to log in Mobile Secure: Account, Username and Password.

But once an enterprise IdP is configured correctly in Mobile Secure (see related documents at the bottom of this page), Mobile Secure Admin SAML is immediately available and it is sufficient to use the following URL format: https://<account>-portal.* to be authenticated.
Then, if the user is not already logged on, there is a redirection to the IdP log on page where the user has to enter his credentials (for example, email address and password) before accessing Mobile Secure (below a screenshot of SAP cloud identity).

If the SSO fails,



it is still possible to login without SSO. In fact, there is a redirection and the URL format changes to https://portal.* where to enter Account, Username and Password.
It is a manual authentication using either Cloud or Enterprise Authentication AD/LDAP (if this was enabled in Mobile Place). Of course, the authentication type is based on the user type that can be a cloud user or an enterprise user. The table below summarizes all possible scenarios.

Talking about cloud users, Mobile Secure Admin users have an ACCOUNT_ADMIN role. The first user that is created has a cloud ACCOUNT_ADMIN role and, at any point in time, there must be, at least, one user with that role. The initial cloud administrator user can create other admin users and an admin user can delete the initial admin user if he has an ACCOUNT_ADMIN role. These users can have different authentication types: cloud or Enterprise authentication. We can decide not to have Cloud authenticated administrative users for improved security.

There is no auto-onboarding for administrative users in Mobile Secure but it is possible to promote existing users with MOBILE_PLACE role to administrative users by granting appropriate roles. This is flexible so that different types of administrative users (Account Admin, Device Admin, MAP Admin, APP Catalog Admin) can be created.

Let us suppose that a new IdP user is created. Because, there is no auto-onboarding in Mobile Secure, an IdP user can be either created or imported by Mobile Place that instead supports auto-onboarding of users from IdP into the system. The new imported user is a Mobile Place user. For example, suppose that we have a new user in the enterprise IdP. This user cannot log into Mobile Secure even though SAML SSO is configured correctly. However, if auto-onboarding is enabled in Mobile Place (“Allow only imported users to connect” option has to be unchecked in Mobile Secure > Account > Settings when Single sign-on is enabled), as soon as the user navigates to Mobile Place, he is redirected to the IdP log on page for authentication. Then, once logged in Mobile Place with the new IdP user’s credentials, he is asked for confirming user details, user preferences, before becoming a Mobile Place user and being able to browse the App Catalog page.This user has only a role: Mobile Place User, hence he cannot log into Mobile Secure. However, an admin user with ACCOUNT_ADMIN role can grant administrative roles to the new user. Now he can log on Mobile Secure leveraging SAML SSO. This means that Mobile Secure can be accessed by this user using the following URL format:


and without entering username and password (it could be required to confirm in a pop-up window that the certificate used by the web browser is correct).

Similarly, it is possible to log on directly to Afaria administrator console, using the following URL format:


This URL only works if enterprise IdP is already configured. In other words, an administrative user with no enterprise identity provider credentials cannot use that URL. Instead, he must login to Mobile Secure Portal and navigate to Afaria Admin console.

HANA Analytics URL cannot use SAML because the format does not include any account information so there is no way to know which IdP to contact for initiating authentication. So it can only use password based cloud or enterprise AD/LDAP authentication. But if the user does not have enterprise IdP credentials or cloud credentials, he can login to Mobile Secure Portal using SAML and navigate to analytics page.

Once an authentication type for a user has been assigned, it cannot be changed. To switch to a different authentication type, the user has to be deleted and recreated. For example, if user A has cloud authentication type assigned and we want to change it to enterprise authentication, user A can create user B with a different email address, and use user B to delete user A and eventually change the email address of user B.

We have already mentioned that the format of the URL to access Mobile Secure is <account>-portal URL (see architecture below). Trying to access Mobile Secure portal using a web browser triggers an authentication request from Mobile Secure Service Provider to Mobile Place Hosted IdP. This generates a second authentication request to the Enterprise IdP. This is due to the fact that there are two separate domains: portal ( and mobile place (<account> Hence, Mobile Secure acts as Identity Provider Proxy. However, user is required to pair the Mobile Place Service Provider with his enterprise identity provider only once for both Mobile Place and Mobile Secure (details in the related documents at the bottom of this page).



Related Content

Related Documents

How to setup Mobile Secure to authenticate against SAP Cloud Identity

How to setup Mobile Secure to authenticate against MD ADFS

  • No labels