4 ms·

>Whenever possible, use the email as the user identifier. You can manage with any other kind of identifier, but debugging is significantly easier, since you don

>Whenever possible, use the email as the user identifier. You can manage with any other kind of identifier, but debugging is significantly easier, since you don't have access to the customer's IdP to know the correspondance between an actual user and its opaque identifier. This is an assumption that a number of service providers run in to when setting up a SAML relationship with Stanford’s IdP: Not every Stanford person has a published email address. In particular, people who have been sponsored for accounts (in order to log in to Stanford systems) don’t have their email address published (we don’t have their permission to do so). Email addresses can also change. As was mentioned, there are opaque identifiers that uniquely identify someone and that do not change. We also provide the person’s SUNetID (their Stanford username), even if there is no email address.

victorNicollet 7y ago
I agree that the service provider shouldn't expect the SAML identifier to be an email. I suspect that the SUNetId is something readable (based on the human's name) as opposed to a fully opaque alphanumeric string ? On the other hand, having emails (or namespaced identifiers that look like emails but aren't) does provide a nice way to start the login process from the service provider's login page, as opposed to having to start from the IdP side, since the service provider can infer which IdP to use based on the identifier's namespace.
- CaliforniaKarl 7y ago
  >I agree that the service provider shouldn't expect the SAML identifier to be an email. I suspect that the SUNetId is something readable (based on the human's name) as opposed to a fully opaque alphanumeric string ? Yup. For those curious, you can find Stanford's list of released-by-default attributes here: https://uit.stanford.edu/service/saml/arp https://uit.stanford.edu/service/saml/arp >On the other hand, having emails (or namespaced identifiers that look like emails but aren't) does provide a nice way to start the login process from the service provider's login page, as opposed to having to start from the IdP side, since the service provider can infer which IdP to use based on the identifier's namespace. Yup, totally agree, and that's one of the annoying things about SAML. In Stanford's case, that's the eduPersonPrincipalName attribute.

victorNicollet 7y ago

I agree that the service provider shouldn't expect the SAML identifier to be an email. I suspect that the SUNetId is something readable (based on the human's name) as opposed to a fully opaque alphanumeric string ? On the other hand, having emails (or namespaced identifiers that look like emails but aren't) does provide a nice way to start the login process from the service provider's login page, as opposed to having to start from the IdP side, since the service provider can infer which IdP to use based on the identifier's namespace.

CaliforniaKarl 7y ago
>I agree that the service provider shouldn't expect the SAML identifier to be an email. I suspect that the SUNetId is something readable (based on the human's name) as opposed to a fully opaque alphanumeric string ? Yup. For those curious, you can find Stanford's list of released-by-default attributes here: https://uit.stanford.edu/service/saml/arp https://uit.stanford.edu/service/saml/arp >On the other hand, having emails (or namespaced identifiers that look like emails but aren't) does provide a nice way to start the login process from the service provider's login page, as opposed to having to start from the IdP side, since the service provider can infer which IdP to use based on the identifier's namespace. Yup, totally agree, and that's one of the annoying things about SAML. In Stanford's case, that's the eduPersonPrincipalName attribute.