Skip to Content


SSO enhances user experience. Certificates are a good, but complex solution. You need a PKI. SSO token are the second best way. Users will be asked for credentials and tokens must be shared securly between Apps.

I am a mobile user. And when I don’t have my smartphone on me, I can become really nervous: Has a customer send me an email and is waiting for a reply? Do I need to approve a workflow? What am I missing on my Twitter stream?

There are times, however, when using my phone makes me really upset: Mostly that’s when apps require me to log in. For example, when I download a new app and need to enter credentials for the initial login, often with app specific policies. Or when the session for a social media app has expired, requiring me to log in with another set of credentials. But business apps, they are the worst: Not only do you have to login every time you use them, they also require these super secure business passwords, making it extra painful to enter them on a smartphone.

And don’t we all hate to enter user names and passwords on these tiny touchscreen keyboards?

My personal workaround is to use only a handful of different logins for the various apps. Unfortunately, I do not always remember which login I have chosen for which app.

What really would be helpful here is a Single Sign On paradigm for ALL of my apps! As an icing on the cake it would be nice if this SSO System could also handle different personalities (IDs when we want to talk techie), but this is maybe another blog post.

Single Sign On

Now – do you work for a company that has SUP deployed? Than you are in luck, as your app developers can come to your help!

Here’s how, let’s get our hands dirty and talk about the details of Single Sign On (SSO):

Often in discussions the term SSO is used for various techniques which play in the area of authentication and authorization. But people understand different things if you say SSO.

The topic “Single Sign On for App” – as we have discussed – is a way to enrich the User Experience on mobile devices by prevent annoying log in screens. In another Single Sign On scenario you have two distinct backend systems that your App needs access to, but of course you only want to login once. Let’s call this “Single Sign On for Back-ends“.

In a discussion about SSO – make sure all participants are talking about the same scenario.

Certificate Authentication

The “easiest” way for the end user to achieve SSO for Apps and SSO for back-ends with one technology is using X.509 certificates. You can use the identity provided by a certificate in all installed apps (limits apply) and pass that identity to your back-ends, which are also enabled to use that “format”.

BUT, in order to use certificates you would use a PKI – a Public Key Infrastructure. This PKI is responsible for provisioning certificates, establish trust between users and systems, apps and backend systems, let you revoke certificates and so on. The effort to plan, create and maintain a PKI can be substantial.

From a user perspective the Certificate Authentication is the easiest way: The user does not even have to provide his credentials – log on is working seamlessly in the background. On application start the app is retrieving the certificate from the secure store (normally the keychain) and passes it to the mobile middleware. The SAP Mobile Platform will then use the provided certificate information to pass it to the various, certificate enabled back-ends (SAP and others).

SAP is offering solutions for X.509 certificate authentication in its mobile offerings. SUP for example supports User Authentication via X.509, and these can be distributed to devices using Afaria.

Token Authentication

Since this “Certificate” thing is complex to implement and maintain it is not always the best choice for mid-size and smaller companies and partners. So what are the alternatives? What about Single Sign On via tokens?

In a Single Sign On with Token scenario the user logs in with his authentication credentials – yes we need that, at least once every here and then.

With these provided credentials the app can request a resource from the SMP. Since this request does not contain a token, SMP will ask a configured token provider with the users credentials for a new token. The token provider verifies the credentials and returns the user token.

Typically the token is just a large, more or less random string in the http header. Sometimes the token provider resides on the network edge – meaning that the request has not to be issued against on premise systems – this prevents DOS kind of attacks against the internal infrastructure.

SMP will now use the token to impersonate the user against the back-end and will also send it back to the app. The app now stores the token securely on the device and resubmit it with every subsequent request. After a while those tokens are invalidated and the process starts all over again – starting with asking the user for his credentials.

In this scenario we don’t have to store the credentials on the device, which is truly a security advantage. Stored tokens typically can be invalidated manually if compromised, so this scenario gives us a good user experience and a more secure system.

For now this token scenario allows an App to validate against multiple back-ends, but does not allow to be used by multiple Apps on the device. In order to do so we have to share the token between devices. Since Apps are today running in isolated environments (sandboxes) it is not easy to share that information. Typically you can do using URL Schema to pass information between Apps – but this only works unencrypted, and malicious Apps could also register for your URL Scheme. For now the only option we have is to store in the keychain – if available for your platform.

As an example of who SSO Tokens can be configured read the attached How-To Guide. It gives a good overview which steps are necessary to configure SUP (up from 2.0.1) for the use of an SAP token provider and use it in an MBO based App.

Have Fun,

Martin Grasshoff

Want to read more:

How to enable and configure SSO for SUP

How-To Guide “SSO with SAP token for MBO-based Mobile Apps”

NetWeaver Single Sign On

To report this post you need to login first.


You must be Logged on to comment or reply to a post.

  1. Massimo Perego

    Hi Martin,

    just today i try to connect to unwired server through certificate.

    I insert a .p12 file in the bundle app and I use the code below to attach the certificate to sync profile and then synchronize

    NSString *certPath = [[NSBundle mainBundle] pathForResource:@”sybase101″ ofType:@”p12″];

    SUPLoginCertificate *lc_resource = [cs getSignedCertificateFromFile:certPath withPassword:@”password”];


    Obviously the synchronization failed and in the log i found a login failed exception,

    there is something i have to configure Unwired Server side to get the authentication via certificate?

    Thank you

    1. Martin Grasshoff Post author

      Hi Massimo.

      There could be many reasons for the logon to fail in this scenario. And yes, there is a lot to setup on the server side to get certificate auth going.

      First, I wonder if your password is really “password” and if your app id is really “sybase101”?

      It seems that the code I am seeing here was taken from the Sample Code page provided on Infocenter.

      If you want to check what has to be done on the server side, please check the Security part of the documentation – Security on Infocenter.

      From client perspective your code looks correct.

      1) Retrieve the certificate

      2) Add certificate to Sync Profile

      3) Connect to the server and synchronize.

      Hope that set you on the right tracks.

      Kind Regards,


      1. Massimo Perego

        Thank you Martin,

        you are right, my certificate and password are different,

        I paste the infocenter code to help to understand the code i used.

        Thank you for the link, I’ll check that!

  2. Andreas Wurzer

    Hy Martin,

    could you explain to me  how automatic user onboarding (automatic registration in SUP) is done when using X.509 certificates? What will be the username when usin certificates? Is SUP extracting the username somehow from the certificate or is the user-name returned from the backend system after passing the certificate from SUP to the backend?

    Kind Regards,


    1. Martin Grasshoff Post author

      Hi Andreas.

      In general the automatic onboarding works like this:

      Login – the user sends his ID (credentials or in case of an certificate-his certificate information)

      Authentication – the configured security provider (e.g. CertificateAuthenticationLoginModule) authenticates the credentials or certificate based on the implemented rules of the login module. For certificates it checks the certificate chain. Authentication is always delegated to already existing systems like LDAP or Windows Domain Auth.

      Connection registration – The security provider creates a Principal based on the provided login information. Typically this is the username or the email adress of the user – something that is human readable. Sometimes it is just an ID with seemingly random characters. This value is typically attached to the name of the security configuration: Where is the Principal and certsecur is the name of the security configuration. This is then paired with the device ID and an application ID.

      Connection activation – if there is an Application Connection Template it will now be associated or copied to the freshly Application Connection.

      Application activation –  the new settings from the Connection Template will now be synchronized down to the device. During this the device may also update the Application connection with additional information like IMSI, device type, native push configuration information and the like.

      An important role in this procedure is the Security Configuration. Since it is based on JAAS (Java Authentication and Authorization Services) it is possible to code your own Login Module that implements exactly the behavior that you want or integrate the login method you are looking for. For example Unix Authentication.

      You can find information about how to do that in the Developer Guide: Unwired Server Runtime.

      Hope that answers your question.

      Have Fun,


  3. Bob Douglas

    Hi Martin,

    As a learner about SMP and interested about what you explain in that post, can you tell me if it’s possible to achieve SSO for IOS with SMP and SAP Backend?

    And it’s possible to have more than 1 app using the same credentials in IOS where there isn’t a shared key store?

    Thank you

    1. Martin Grasshoff Post author

      Hi Bob.

      Well that’s exactly what I meant. When you say “for iOS…and SAP Backend” what do you mean? SSO on the device? Or SSO on the device with multiple SAP backends? Or only an App with multiple backends?

      Why is there no “shared key store” on iOS? There is.

      Searchword: keychain-access-group , how to share data between Apps


      1. Bob Douglas

        Hi Martin, thanks for your answer. Sorry because due my lack of knowledge I’m not asking the questions properly. I’ll try to explain what I want to achieve:

        1. My first purpose is to create 1 IOS app that uses the same credentials to connect to SUP and to call the backend. This user is stored in an LDAP but then I don’t know how technically use this credentials to call the back end… Or maybe I’m doing a bad approach, I’m not sure at all.

        2. The second purpose, is to create a 2nd app and just be able to use the same credentials in both apps to make it simple to the user so he only has to log in the first time with the first app he uses.

        1. Martin Grasshoff Post author

          Hi Bob.

          That’s pretty simple and straight forward.

          If you use our HTTP/REST API you pass the credentials using HTTP Basic auth. The server validates the credentials against the LDAP (create a Security Configuration in order to do so) and passes the credentials to the backend.

          If it is ok with you you can store the credentials in the key chain of iOS and share them across apps.

          This behavior imposes a security risk, because the credentials are stored on the device. This is not always compliant to customer rules, but if it is ok, then it works perfectly.

          Find more information about setting up a Security Configuration in the docs. Don’t be afraid to use and read it.


  4. Nan Wang

    Hi Martin

    thanks for your very detail description. I have following questions:

    1. according to the how-to document, it show how to connect to SAP backend and the cookie name must be MYSAPSSO2. My question is, Could SMP integration with other SSO solution? can we say, if the sso solution is cookie based or token based (cookie or header), SMP can integrated with them? do we have a list to show which solutions were tested or we have references to integrate with them?

    2. if we use the token based solution, does it mean we have to use the https as the transport protocol. If someone monitor the network and get the token, he can access our app? can we authenticate end user by more factor? for example mobile phone number, device id and even the dynamic token (like RAS token). Do we have any document to show the best practice?


    1. Martin Grasshoff Post author


      Well, in general we allow to let the user define the name of the token. This doesn’t mean it will run with other token providers. The communication flow, expiration time and other factors will impact the ability to use other provider tokens. In general it always implies a risk if you use unsupported features – even if it (seems to) works.

      Yes, always use https. There are just no exceptions. Even during development use https.

      Typically it can be considered that the certificate (something you own) and the username/password  (something you know) would suffice. In addition during the onboarding process the device, user and app are paired which adds to the overall “situation”.

      Yes, if someone owns your secrets you are…..

      1. Nan Wang

        Hi Martin

        Can we integrate with non-sap token provider  by customised the security provider? there are many customer use the non-sap sso solution. In the smp 2.x, we can create the customised CSI component. is it the right way? But I can’t find these API in SMP 3.0 now.

  5. Frankie Fan

    Hello Martin,

    I want to configure the idp for apps which are hosted on hcpms. From this blog(Appendix N: Using SAML with Kapsel, I have saw that in SMP Cloud edition, we can configure the idp under tag SAML for each app. And we can using kapsel login plugin by using the following code:

    “auth” : [ { “type” : “” } ]

    But in hcpms, there is no options to configure SAML.Do you have any advice?

    1. Martin Grasshoff Post author


      in HCPms it is sufficient to select “Form” for the Security property. Still you need to configure your HCP account to trust you IdP. I’m not sure if this is possible on trial though.



Leave a Reply