...
And remember, just because you are sending EPPN as the "user id" to a Cloud Service, and even if the Cloud Service Provider itself refers to that as the "login name", that does not mean that your users are going to have to fill in their EPPN as their Username when they login. EPPN is what we send for them, it is independent of what the user uses to login.
Here is a diagram that illustrates how this all "fits together":
A. College sends provisioning feed to Cloud Service Provider, making sure the "user_id" is going to match what the Shibboleth IdP will send, either the jsmith@collge.edu or 12345678@college.edu.
B. User logs in at college, to the IdP, with their Username (jsmith).
C. User record in AD/LDAP is found, password verified.
D. IdP pulls the needed attributes out of AD/LDAP for the user, including whichever identifier will be used to "construct" the EPPN. It "constructs" the EPPN by taking that identifier and adding the scope for the college to it, in this case "@college.edu".
E. IdP builds and sends the SAML response, including the EPPN.
F. CCC IdP Proxy adds the CCCID to that response if needed, and sends it on to the cloud service.
G. Cloud Service finds the user in its user database (built from the provisioning feed) by looking for the user with the EPPN it just received in the SAML response, and presents that user their information/services.
Attribute Summary
Minimally Required Attributes
...