saml proxying scoped attributes...best practice

Bobby Lawrence robertl at jlab.org
Tue Nov 12 16:13:09 UTC 2024


So this is one of the things I never quite understood regarding hashed/opaque identifiers.  I understand its value with respect to preserving privacy, but most of my SPs need to lookup a database record of a valid user to determine authorization roles/rules.  How am I to correlate the identifier to a database record if its hashed?

I also don’t quite understand your uid comment.  I understand that the uid may not be suitable for federated services, but isn't it still suitable within my organization?  All the SPs I control understand the concept of a uid because they used to receive it via a login form or Basic auth and (along with a password) used it to authenticate the user against our LDAP directory.  They then used that identifier to determine authorization by doing a database query.  Now the IdP does the authentication and my SPs don’t need to talk to LDAP anymore, but they still need the uid to determine if the user is valid for the service via the db query.  If the uid is being passed back from my IdP, its definition/semantics is basically the same - is it not?  It’s the identifier that the user logged in with.  It might not look the same when it gets passed back from an upstream IdP (because I resolve it via a scoped attribute), but as long as my SPs can deal with that difference, I don’t see why its not suitable to use...


-----Original Message-----
From: Cantor, Scott <cantor.2 at osu.edu> 
Sent: Tuesday, November 12, 2024 7:44 AM
To: Bobby Lawrence <robertl at jlab.org>; Shib Users <users at shibboleth.net>
Subject: [EXTERNAL] Re: saml proxying scoped attributes...best practice

If you control the SPs, then my recommendation is that you should produce the standard subject-id Attribute for those SPs, probably basing it on a hash of a proxied identifier in the proxy case and locally managed in the local case.

I would never use uid for anything outside the IdP itself. It has no definition or semantics, so it's not suitable for anything.

-- Scott




More information about the users mailing list