SSO Between SAP ABAP and third party Tomcat Application

[Former Member]

Hi Experts,

I need to do the single sign on (SSO) between SAP ABAP which is CRM 7.0 and Third party Tomcat application. Could you please guide me how should I configure the same

Can you please clarify my below queries

Scenario is like SAP CRM system will call one URL which is of tomcat application and that url ask for logon data of tomcat application.

For trial purpose I have maintained same user id and password between ABAP and tomcat. now my requirement "It should not ask me any login screen and when I call url from CRM system it should directly redirect to tomcat"

I decided to follow with STRUSTSSO2 logon ticket method. Does tomcat support this?

How does tomcat recognise the SAP user?

Appreciate your reply.

Thanks,

Aditya

[AntalP]

Hi Aditya,

Please review SAP Note 304450 -  Singel-Sign-On with SAP logon tickets in non-SAP systems.

Best Regards,

Antal

[Former Member]

Thanks Antal for reply and the note is useful

But I am confused with how tomcat will recognize SAP system's user though the certificate is imported in Tomcat?

Can you please clarify

Thanks,

Aditya

[mvoros]

Hi,

that library gives you ability to parse and validate logon cookie issued by SAP ticket. You pass it a cookie content and it gives you back if it's a valid cookie (signed by trusted cert) and all the fields such as username. So to use it in Tomcat you will have to define a custom authentication module that uses this library. It reads cookie, parses it and validates it with this library and if everything is OK then it authenticates user. If you need to know how to write a custom logon module for Tomcat then you need to find a better forum.

Cheers

[mvoros]

Hi,

first, you need to clarify roles of your systems. Let's use SAML language. There are 2 system roles: identity provider and service provider. A service provider provides services to a user (e.g. web UI of CRM system where a user can create an order). A identity provider authenticates user e.g. by using username/password and then issuing signed ticket that is accepted by all service providers. Note that one system can have both roles. Also note that usernames do not have to be same for a user in all systems. A service provider can do a mapping for usernames. In case of service providers they don't need to know password for users and it's actually good if they don't know them.

In your scenario you seem to have two options: you can set CRM system as identity provider or your Tomcat application server. Whenever users want to use a service provided by one of the systems they need to be redirected to identity provider for authentication first.

So let's say that CRM system is identity provider. When users access a CRM URL then they get a standard logon screen of CRM system. After successful authentication they get a SSO cookie and they can use services provided by CRM. Tomcat application server needs to implement a custom logon module. I don't think that SAP method is supported out of the box. So when users try to access services provided by Tomcat it will check if there is a valid SSO cookie. If not it needs to redirect user to CRM system. If there is a valid cookie then it will let users in. The note mentioned by Antal provides a link to library that can validate SSO cookies issued by SAP systems.

The other option is that Tomcat has a role of identity provider. In this case you need to be able to generate a cookie that can be verified by SAP system. Unfortunately, there is no officially supported library that allows you to generate SSO cookies. There is an supported way how to do this.

There is also third option that both systems are identity providers. I would not go this way because you would have to sync passwords between systems and that's a really ugly solution without too much benefit.

Also note that if identity provider is down then users can't use services. This is not true for the third option because any system can authenticate user. So that's one of the factors for deciding which system will be used as identity provider.

You could also use SAML instead of SAP proprietary SSO solution but that would require some additional work (CRM system does not have capability to be SAML identity provider, it can be only service provider).

Cheers

[Former Member]

Thanks Martin for reply. We were thinking of this method too

The following limitations apply for the current version of PPSS(Tomcat application) related to SAML 2.0 support:

SAML version 2.0.

• Identity provider (IdP) initiated SSO with HTTP POST binding.
• No support for SAML 2.0 attributes.
• If encryption is required for a SAML 2.0 assertion, the entire Assertion section must be encrypted.
  • The supported block encryption algorithm is AES-128.
  • The key transportation algorithm is RSA-v1.5.

Additionally, to access PPSS through SAML 2.0 single sign-on, the “NameID” specified in the SAML 2.0 assertion must contain a valid user name in PPSS. For example, given the following SAML 2.0 assertion, “john” must be a valid user in PPSS(Tomcat application):

<saml:Response ...>

<saml:Assertion ...>

<saml:Subject>

<saml:NameID ...>john</saml:NameID>

</saml:Subject>

</saml:Assertion>

</saml:Response>

Can you suggest on this

Thanks,

Aditya

[mvoros]

Hi,

I am not sure from your comment if Tomcat can be identity provider or not. I would say no. It can be just service provide that uses SAML for user authentication. SAP CRM system can be SAML service provider as well. So in this case you would need to introduce additional system that would take identity provider role. So when users hit the one of the backend systems (CRM or Tomcat) then they would get redirect to identity provider to perform authentication. There are some commercial as well as open source systems that provide SAML identity provider functionality. This could be a good future proof solution but you can see that it will require some investment (time & money) and you should not make a quick decision.

Cheers

[Former Member]

Hi Aditya,

I would suggest to even step back a bit further. If you want to do SSO, you may need to have some identity management (IdM) in place, where all user are stored within unless you want to do adhoc user provisioning or some sort of pseudonymous access to the tomcat server. If you know what to do about users you can decide on mechanisms. The suggestion from Martin would be my best bet as well and I would discourage the usage of logon tickets for security reasons. However there are other options like X.509 tickets and Kerberos based authentication as well. For this to decide, you even need further things to take into account like who will access the servers. Is it only comapny internal users, then Kerberos might be even more favourable. There is nice document comparing the diffferent methods based on SAP NetWeaver SSO 2.0 by Jens Koster. For Tomcat there is also a windows authentication how-to provding info on how to enable SPNEGO on Tomcat.

If you have decided to go for SAML2, the IdP usually should be on a seperate system from any business application server. There is more than one option. You can buy a product like for instance SAP NW SSO or if sufficient use a SAP Enterprise Portal, which can be used an SAML2 identity provider as well. There is some more info on this in this article from Dimitar Mihaylov and Yonko Yonchev.

For sure you can also use the tomcat system itself as an IdP, for instance with the higgins SAML2 IdP or using shibboleth, however in this case you must have some sort of IdM in place, so higgins and the SAP CRM have the same users.

The mapping of the users between the IdP and the SAML2 service providers usually is the easiest thing. This can be done in e-mail, user account ID, some other id and will simply based on the data stored in the user store for the system, which acts as the SP.

Back to your question. The limitiation simply states, that the NameID needs to contain the user account ID (logon name) of a user on the tomcat application server. So it seams, that the PPSS does neither support adhoc user creation nor pseudonymous access. In this case you need an IdM to replicate users between the system or set up some manual replication. What is more of a problem is the statement on IdP initiated SSO. This is unusual for SAML2 and in fact will make it most likly impossible to use PPSS at all. What you need is a system being capabale of SP initiated SSO. For SAML2, the handshake is usually an app A is sending a user to some app B on a different server. This server will check, if he has already some konwledge on the user and if not trigger the SAML2 authentication by sending the user to the IdP, which will create a SAML2 assertion (possibly first checking the users credentials) and then send the user back to the server of app B. However there are other SAML2 SP implementations in place (see google) of which some will be able to support SP initiated SSO as well. One exmaple would be the openSAML implementation or again shibboleth.

Regards,

Patrick

[Former Member]

Hi Martin,

Thanks for your input. Let me try with this option. Will update the post accordingly

Aditya