reverse mapping with UME

[Former Member]

I know you can map J2EE/UME user IDs to a back end system, but can you map User ID's from another system into the J2EE?

Here's a scenario:

You have an external system that can pass SAML assertions, but users authenticate to that 3rd party system with a user ID different than what's being used in SAP.

Could we setup a mapping table in the J2EE that the UME can use to a.) receive the SAML assertion with the 3rd party user ID and b.) translate it and authenticate to the SAP J2EE with the SAP user ID?

[Former Member]

Hi,

I strongly doubt that this is possible.

But: You can enhance/modify/replace the existing logic for SAML logins (i.e. the SAMLLoginModule ) to include your custom mapping.

Regards,

Dominik

[tim_alsop]

Hi,

When a login module exits, the userid (expected to be a SAP userid) is stored in memory in a 'sharedState'. This 'sharedState' might be read by the CreateTicketLoginModule in order to know what SAP user to use when creating an SSO2 login ticket (e.g. SSO browser cookie). If the CreateTicketLoginModule is not used, then SSO will not be possible, but authentication will still be completed using the SAP userid in the sharedState memory.

With the above in mind, any login module which is configured to execute after the authentication login module (e.g. SAML login module) can perform a mapping of the userid in the sharedState into an actual SAP userid. The output of this mapping login module can then be used as the final desired userid.

However, I beleive that the userid output from the SAML login module is validated to check if it is a valid SAP user, and an exception is raised if not. This means that you will need to add all external userids as SAP userids, even though a mapping login module might change this userid to something else before the authentication login stack is complete.

I had an email discussion with Patrick Hildenbrand from SAP about this recently and he confirmed that the login module (e.g. SAML login module) is validating the userid as a SAP user. I argued that this means the use of mapping modules is not easy.

Some SAP supplied login module are more compatible with mapping because they have been coded not to call the validate function at exit, but instead they exit and allow the mapping module to map the authenticated user onto a SAP user, then validate this user instead.

I hope this helps ?

Thanks,

Tim

[Former Member]

Hi Dave,

please have a look at the docs for <a href="http://help.sap.com/saphelp_nw2004s/helpdata/en/b3/56e39da6e1a3438b42c29c6b2da17b/frameset.htm">Mapping SAML Principals to SAP J2EE Engine User IDs</a>. Essentially what you have to do is to provide a mapping facility which is called by a logon module. An example of such a module is

<a href="http://help.sap.com/saphelp_nw2004s/helpdata/en/40/099c4167d5164c9e4b1e347c8cdc73/frameset.htm">also in the docs</a>.

Regards,

Patrick

[tim_alsop]

Patrick,

Surely there is a problem with this approach since the output from the SAML login module (in shared state) will need to be a valid SAP userid. This is because the SAML login module is calling the refreshUserInfo() function which validates the user. If the SAML user is an external user that is yet to be mapped by a login module later in the stack, then this validation is likely to fail unless 'dummy' userids for all external users are added to SAP to allow the validation to pass, and then the mapping module will be invoked.

Thanks,

Tim

[tim_alsop]

Patrick,

Sorry. I think I have already answered my question. I found in the doc that Mode=Standalone is required when no mapping module is used, but Mode=AuthenticationStatement is required when using a mapping module. I therefore assume that the validation is not performed at exit when Mode=AuthenticationStatement.

Thanks,

Tim

[Former Member]

Hi Tim.

right, that's what the docs are for