In a traditional SAML flow the following happens. The goal is to enable user Aladár (A) to manage the authorisation of user Béla (B) authorization to service S, but in a way that this information is not maintained in S but in an external source.
- A logs in on the web interface of the MMS, a SAML SP and an account is created.
- A creates a Virtual Organization / Community / Group - terminology depends on the actual tool but let's call it (VO)
- A wants to invite Béla (B) to to his VO. In order to do this, he needs an email address to B. This email address serves as a trust anchor for the moment, therefore it needs to really belong to B and not be comprimised.
- A sends an email invitation to B with a link containing a token.
- B follows the link to the web interface of the MMS, prompted for login. B may already have a login (for previous participation in other VOs) or needs to create a new one. B may log in with a federate account but it could be the case that there is none, and a local account is created or a VHO account is used. This scenario is made possible by the fact that really the access to the email inbox is what provides the trust for the VO membership.
- After creating/accessing a local account, the token sent in the link is processed and B's account is now associated with the VO.
- B will eventually access a service that needs this membership information, commonly called entitlement. The service will perform a login flow and then with B's user identifier queries the MMS backend, for instance a SAML AA or an integration. This requires the usage of the same user identifier that was used at the MMS, typically a common OIDC/SAML source.
- A may revoke the entitlement at any time, which will take effect at the next session: the service accessed will query the MMS and will not get the entitlement.
...
- A creates a VO at the MMS service
- A sends an invitation to B to the VO
- B visits the link and receives the card, which is added to the wallet.
- B visits a service that needs the entitlement and presents the card.
- (the card is verified in the common registry, therefore revocation is possible
With this solution B does not have to use the same login (i.e. the MMS and the target SERVICE do not need to be in the same federation)