SMP mobile app Integration with AD server

[NareshChittoor]

Hi Team,

Please advise your views for below requirement.

We developing an SMP mobile app, which will authenticate through AD server and have configured as "Basic Authentication" in SMP Cockpit.

App authentication through AD is success, but issue is whenever AD password expires, NW servers also requires to change and maintain the same password created for AD authentication. else we gets an error message "Forbidden 401".

Appreciate your suggestions and thoughts to over come the solution.

Regards

Naresh

[Kevin_SAP · Accepted solution]

You should probably use Principle Propagation with LDAP.  See SCN article http://scn.sap.com/community/developer-center/mobility-platform/blog/2015/07/04/smp-3-security--prin....

Regards,

Kevin Bates

[NareshChittoor · Accepted solution]

Thanks Kevin for the link and apologies for late reply due to travel.

Our requirement is : have developed SMP based native mobile app, we need to authenticate our mobile app through AD credentials.

When we select Basic Authentication in SMP Cockpit, mobile app validating the same password in both (AD and NW server)

Please let me know the option and how can we achieve the AD authentication to our SMP mobile app to login success.

Note : NW and SMP is not in single sign on.

Regards

Naresh

[D_Olderdissen · Accepted solution]

I am not sure I full understand the issue in the first place.

1. User enters AD credentials into his native SDK based app

2. SMP uses basic auth against AD

3. OData request is fired against NW and same user credentials should be used as before

Naturally, this requires that AD and SAP user space are in Sync. If not you need some kind of AD = SAP user mapping some where else or use a technical user.

Usage of a technical user is highly discouraged

• Loss of traceability and audit functions in SAP
  • As all data access is done by the same technical user (when looking from the SAP perspective) debugging and tracing will get very difficult.
  • Audit functions will no longer work, might even be a legal issue in regulated industries.
• License tracking will be difficult - access to SAP backends does require a SAP user. A techincal user "hides" the actual mobile users behind SMP from the regular license count tools. That may get your customer into a license issue with SAP without him knowing about it.

In theory, you could also disable NW to check for credentials, kind of like a technical user - but you should at least establish a trusted HTTPS connection between SMP and NW so you do not open your self up to the world. BTW - this is also highly discouraged.

Just to make it clear - the recommended approach would be to have a user sync / mapping between AD users & SAP users. This way our different SSO options (MySAPSSO2, PrincipalPropagation) can be used and the SAP system auditing / logging remains fully functional.

Maybe you could describe a bit more about the general user setup?

Cheers,

Dirk

[NareshChittoor · Accepted solution]

Thanks Dirk for the info provided and it's helpful...

If we set "Basic" in SMP Cockpit, our mobile app validating for the same password in AD and NW server (I am really unable to understand, from where this password check happens).

Is there any way we can bring SAP NW and AD in to trusted connection ?

How can we achieve through SMP connecting mobile app with AD credentials?

Please advice.

Regards

Naresh

[Kevin_SAP · Accepted solution]

I answered this in the above with the provided link.  You can use Principle Propagation between SMP and NW.  The sample in the link shows using SAML to SMP, that can be replaced with AD, but the Principle Propagation between SMP and NW shows creating a trusted connection.  I've had customers use this solution already.

Regards,

Kevin

[NareshChittoor · Accepted solution]

Thanks Kevin for reply, do we need to generate certificate for this principal propogation method? if so what kind of certificate need to generated and from where? please through some lights on this, Appreciate your advice..

Regards

Naresh

[Kevin_SAP · Accepted solution]

The link above walks you through it.  You can start by just using the smp certificate for testing as the document indicates http://scn.sap.com/community/developer-center/mobility-platform/blog/2015/07/04/smp-3-security--prin....

[hofmann · Accepted solution]

Hi Naresh,

I wouldn`t do principal propagation. It means that your SMP3 will be a CA and create certificates, something you should really talk to about with your security team. You`ll also have to configure the backend to accept certificates, something which depends on your backend. (btw: this should be done, as the best approach is to have certificate based logon on SMP3 + backend).

If you cannot sync SMP3 and NW user credentials and cannot do certificates end to end, you should go for SSO.

[NareshChittoor · Accepted solution]

Thanks Tobias for your inputs, At present we don't have SSO in place. with "Basic" option choose in SMP cockpit, AD authentication is success. But the issue with password (when ever AD password changes, it's asks mandatory to change and maintain the same AD password in NW server) else gets an error "401 Forbidden". How the SMP verify the password in NW server, is there any settings which we can bypass and use that not to verify NW password.

Regards

Naresh

[NareshChittoor · Accepted solution]

Hi Kevin,

We are configuring the principal propogation method as suggested above link. we struck up in below steps under preparation.

1) We have technical user created --> completed

2) need to know from where we can generate / get user certificate for SMP (that is accepted by netweaver gateway)?

3) Do we need to create CA certificate from NW server?

please advice:

Regards

Naresh

[hofmann · Accepted solution]

SMP3 has a component that is responsible for storing the received user credentials (CSI). When you set the backend SSO to Basic, the user name and password are retrieved from there (CSI). When the AD password changed, and the user enters the new password when accessing SMP3, this new password will be passed on to NW backend.

As you can see, if the backend NW system is not aware of the changed password, the user won`t be able to log on. Therefore you have to take of the password sync or use a SSO solution.

[Kevin_SAP · Accepted solution]

This is why I recommended principal propagation (PP), with PP the AD password can change yet it would not affect the SSO certificate with backend NW.  For testing scenarios you can use smp’s base certificate: smp_crt

[hofmann · Accepted solution]

Why would a pw change affect the SSO2 logon cookie? And PP is a higher configuration effort and SMP3 will be a CA. Something that really should be evaluted carefully.

[Kevin_SAP · Accepted solution]

It wouldn't, that's why I suggested PPO which creates SSO with NW and no password is required.

[Kevin_SAP · Accepted solution]

Just use the smp_crt certificate from the SMP keystore for testing.

[hofmann · Accepted solution]

Exactly, that`s why SSO2 is the way to go. Standard, NW systems are used to it and no need to create thousands of dummy certificates for loging on the user.

[Kevin_SAP · Accepted solution]

Well, yes, if the backend is configured for SSO2, that is the preferred way.  Principal Propagation can be used if it isn't.

[NareshChittoor · Accepted solution]

Hi Tobias,

How can we set SS02 certificate validity expiry date for years? if we generate SSO2 cert from SMP server it gives validity for an month. please advice how can we achieve increasing the expiry date of SAPSS02 cert file (the same cert will be uploaded in NW server).

Regards

Naresh

[NareshChittoor · Accepted solution]

Thanks Kevin, noted and will use this for principal propagation method..

Regards

Naresh

[hofmann · Accepted solution]

If you create the certificate without specifying the days parameter, the default value will be taken, which is 30 days. https://www.openssl.org/docs/manmaster/apps/req.html

when the -x509 option is being used this specifies the number of days to certify the certificate for. The default is 30 days.

To cahnge this, specify the number of days you want your certificate to be valid. For a validity of 1000 days:

openssl req -x509 -new -key smp_sso2.pem -out smp_sso2.cer -days 1000

Resulting certificate:

Valid from 6.10.2015 to 2.7 2018