Decide: How should SAML intersect with Sandstorm identity?

[paulproteus]

Context

• We're working on integration of SAML, a typically-corporate identity provider that gives each organization running SAML a lot of flexibility in configuring it.
• When a Sandstorm grain is shared with someone, if that someone signs in, a Sandstorm X-Sandstorm-User-Id gets sent to that grain. Let's call this the "identity ID".
• By Sandstorm's design, the identity ID should be globally unique. See: https://github.com/sandstorm-io/sandstorm/blob/e9e1272ab5199d3ef145672f29f28589071f889d/shell/packages/sandstorm-db/db.js#L33
• Sandstorm typically generates these by doing a SHA256 hash of two things: (accountType, accountIdentifier) (I've made up these terms, but I believe this is accurate).

  Design questions

• For SAML, what should the accountIdentifier be? Some options include:
  • Whatever the admin chooses as the backing for "Name Identifiers". Sandstorm SAML will currently requests urn:oasis:names:tc:SAML:2.0:nameid-format:persistent (see e.g. StackOverflow discussion)
  • Whatever the admin chooses as the backing for Name Identifiers
  • The email address the server provides.

    Research to be done:

• Question: for a sample SAML user, what would they configure as urn:oasis:names:tc:SAML:2.0:nameid-format:persistent (aka persistent name identifier), left to their own devices?
• Question: For publicly-documented SAML/Shibboleth setups, what do experienced admins suggest using as urn:oasis:names:tc:SAML:2.0:nameid-format:persistent (aka persistent name identifier)? To answer this, I'll check the Internet2 login provider documentation.

  Other notes

• Plain usernames are terrible for this. If that's what is typical in SAML-land, then we should tread carefully.
• Email addresses are imperfect because the same person might move from one email address to another, and maybe their SAML server knows they're the same person by some numeric user ID, but if no one tells Sandstorm about this numeric user ID, then that will be sad.
• This numeric user ID might only be available when a SAML server is authenticating its local users, never exposed during federation (perhaps? I'm not sure). If so, it makes a bad global identifier.
• Arguably a privacy bug: If an attacker Mallory can enumerate user IDs for a SAML server, and Mallory can create a grain on a Sandstorm server that has this particular SAML server enabled, then Mallory can share the grain with all user IDs on the SAML server (I think). If Alice visits Mallory's grain, since Mallory convince a user to log in to that server, then the user will see there are grains shared with them, and when Alice visits these grains, Mallory can see Alice's name. For this attack to be interesting, it might require Mallory to run her own Sandstorm server, in which case Mallory would need to get the SAML server to permit Mallory to use it for authentication.
• Given the existence of SAML federation, perhaps the SAML server name ought to be part of the identity ID. Saying that (saml, 'asheesh@example1.edu') owns a grain might not be precise enough. Example: Alice maintains sandstorm.example1.edu and trusts saml.example1.edu to assert email addresses. Alice enables federation to sandstorm.example2.edu which decides to assert that Bob's email address is `asheesh@example1.edu'. I guess that's maybe not a huge problem if SAML admins 100% trust each other.

NOTE: Thanks to @jparyani I edited this to say urn:oasis:names:tc:SAML:2.0:nameid-format:persistent and persistent name ID, rather than urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified and unspecified name ID.

[jparyani]

1 correction, we request a v2 persistent nameId (see https://github.com/sandstorm-io/sandstorm/blob/ba4486cf12ad7780846c9b17b99611e563d96311/shell/packages/accounts-saml/saml_utils.js#L30). It's worth noting that IDPs can seemingly ignore this request, and actually return whatever format of nameId they desire.

[paulproteus]

Thanks @jparyani - I corrected this!

[paulproteus]

For what it's worth, the Shibboleth identity provider (a server that speaks SAML)

by default, the Shibboleth IdP creates the persistent ID proper by calculating the SHA-1 hash of the SP’s entity ID plus a user attribute value plus an admin-specified salt (i.e., the output is 20 bytes, Base64 encoded)

• Read more here: https://www.switch.ch/aai/support/presentations/shibboleth-training-2015/T3P08-IdPv3_persistent_id_migration.pdf
• https://wiki.shibboleth.net/confluence/display/SHIB2/IdPPersistentNameIdentifier

@jparyani says that Okta uses just an email address, which sure is simpler.

UPDATE: See also:

• Someone discussing how they configure Shibboleth for this: http://shibboleth.1660669.n2.nabble.com/IdPv3-and-generating-persistent-NameID-td7614467.html
• https://wiki.shibboleth.net/confluence/display/IDP30/NameIDGenerationConfiguration

[paulproteus]

Shibboleth's approach seems to be pretty reasonable, honestly, although it's not an email address. Curious for @kentonv's +1/-1. The algorithm (take some stuff, then append a "salt", then hash it) seems not to be trivially length-extension-able, but it doesn't strike me as great. It hopefully does prevent enumeration, though, of valid identity IDs, and uses the salt as a kind of server namespace.

[paulproteus]

I've asked two educational SAML users to get back to me on how they configure this, for what it's worth.

[kentonv]

If Shibboleth is baking the SP into the NameID, that's a problem -- it implies that two different Sandstorm servers will get different NameIDs, therefore grains will not be transferable between them.

[paulproteus]

Then presumably the best decision is:

• For SAML, use email address as the stable identifier for Sandstorm, ignoring whatever the server gives us as urn:oasis:names:tc:SAML:2.0:nameid-format:persistent (aka SAML 2.0 persistent name identifier). (Presumably a quick change by @jparyani )
• Write documentation to indicate to Sandstorm users who choose SAML that we treat email addresses as a permanent identifier for now, and tell them they can either file a bug requesting we change that, or accept that if users within their domain switch their email address, they're going to have to clean up after that. (I can own this task.)

An alternative is to carefully write Shibboleth-specific smarts, relying on https://wiki.shibboleth.net/confluence/display/IDP30/NameIDGenerationConfiguration#NameIDGenerationConfiguration-FormatSelectionFormatSelection , but I think that's a bad idea.

@kentonv if you're +1 on this, then I request you close this with a comment that says: +1 (or similar)

[kentonv]

But... SAML's security is designed around authenticating a NameID, not around authenticating an email address. If we use email address as our primary ID, that means that we're putting a lot of faith in the email field to be accurate.

Possible problems:

• Federated Shibboleth servers may not be configured to carefully scrutinize the email address field coming from other servers.
• Multiple users may have the same email address, perhaps because they represent the same user in different roles, or because some sort of placeholder was used ("temporal@gmail.com" is a popular one at Spanish-speaking universities; ask me how I know).
• A badly-run server may have allowed users to sign up with any address without verifying.

So, I am -1 on using email address.

I would like to understand better what the configuration options are for administrators. Is it possibly easy for them to configure Shibboleth to use global IDs rather than SP-local ones? My quota for reading SAML documentation has run out for today.

[paulproteus]

All fair points. I will try find out the answer to your question.