...
A membership managements system stores role and group information.
In a traditional SAML flow the following happens.
- Aladár (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 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.
These may be released as cards. Here, TTL/revokation plays an especially important role.
...