We have an existing Plone site that we want to configure for authentication using SAML2. We are currently testing our Plone site as an SP using collective.saml2. (The IDP we use is currently ours, but that is just for testing. Eventually our customer's supplier will set one up for us, but now we want to test with our own. As a matter of fact, our "mock" IDP is another Plone site, also using collective.saml2)
When we log in to the IDP, we do it with a different login name than we currently use in the Plone site. The Plone site already has Members, and we wish to grant the "IDP" user the rights from the Plone member. So we want to "map" the IDP username to the Plone user. (At this point we log in by e-mail address in the Plone site. What the IDP will use for usernames, we can't be sure. In the end we won't have control over the IDP, so we can't just tell its supplier to use e-mail address for that, too.)
This is likely not unique to a collective.saml2 implementation, i'd think Plone + LDAP (or any other external authentication systems) using different usernames would have the same challenge.
So how does one handle this? Does one change the session username after succesful SAML2 authentication? @jensens if i remember you also used collective.saml2, did you have to do something similar?
I will try to reformulate your question: you have SP site users and you want to map IDP-userids (which use a different format) to those users.
If this is a correct description of your problem, then you have several options. They use the flexibility provided by Products.PlonePAS (based on Products.PluggableAuthService) which is the base of Plone's acl_users implementation.
With PAS, the authentication subtask is handled by the authentication plugin. Its task is to look at the extracted authentication credentials, check whether they fit to some user of this site and return (in this case) the corresponding user id. If you are using dm.zope.saml2, the authentication plugin is typically one of those defined in dm.zope.saml2.spsso.plugin. Their authenticateCredentials does not perform a mapping (but takes the user id as it comes). You can derive your own authentication plugin from one of the standard ones and implement their your mapping.
If your only aim is to give special roles to the IDP-users, you could achieve this with a customized "roles"-plugin. Its responsibility is to associate roles with the current user (identified via its user id). Thus, you could implement your mapping there.
@dieter Yes, that is a good description of our problem. Thanks for your pointers! We already dove into this and also arrived at the same solution. Thanks again for your help.