NameID from Subject

[Lukas Hämmerle]

On 05.08.14 17:14, Cantor, Scott wrote:
>> So it is correct for me to infer that, given my current configuration of
>> >getting persistent-id in the webserver variables, I can try to pass that
>> >value to resolvertest and, if it happens to be reversible then I'll get
>> >a result otherwise there's no hope?
> Yes. And 99% of the time you won't get an answer. There are very few
> people using a database to generate and store those values. It's not worth
> your time in other words.
> 
> Somebody from SWITCH can comment on how they're pursuing this idea, I
> don't know the details of their "liveness" checking solution, but I'm sure
> it involves control over the IdPs, or at least strong suggestions. It's
> not possible to scale it out beyond a sphere of control.

Let me allow to elaborate a bit on this:

What we do in SWITCHaai is instruct our (Shibboleth) Identity Providers to:
* Deploy a database (MySQL) to generate and store persistentId [1]
* Add a PrincipalConnector to the attribute-resolver.xml that
  "connects" persistent NameID to a user (uid) [2]

How this is configured can be seen in our deployment guides [3].
Besides two ADFS-based Identity Provider, all 57 Identity Providers in
SWITCHaai support this. As far as I know, the same mechanism is also
used at a large number of DFN-AAI IdPs.

The goal of the above two configuration points is to allow mapping the
persistentId back to an (LDAP) user record, which is a requirement to
make SAML attribute queries for the above-mentioned "liveness" check.

This check can be performed by any SP in the federation and it basically
returns all attributes of the user out-of-band (without the users's
involvement). Therefore, not only the liveness of a user can be checked
but the SP will get the most-up-to-date attributes from that user.

The user must have accessed the SP at least once (and depending on the
IdP he had to also consent that his attributes are released to this SP).
Only then the SP possesses a user's persistentId. This aspect is
important to understand. The persistentID is a randomly generated value,
which is of course stored in the database at the IdP.

Attribute Queries have the advantage that they allow some new
(non-browser) applications, especially in combination with GakuNin's
excellent AttributeQuery plugin [4] for the SP. The plubin is far more
efficient and faster than the resolvertestbinary (which was not intended
to be used for more than tests).


Best Regards
Lukas


[1]
https://wiki.shibboleth.net/confluence/display/SHIB2/ResolverStoredIDDataConnector
[2]
https://wiki.shibboleth.net/confluence/display/SHIB2/DirectPrincipalConnector
[3]
https://www.switch.ch/aai/docs/shibboleth/SWITCH/latest/idp/deployment/#shibboleth-idp-configuration
[4]
https://wiki.shibboleth.net/confluence/display/SHIB2/Contributions#Contributions-ServiceProviderExtensions

-- 
SWITCH
Lukas Hämmerle, Central Solutions
GÉANT Project Task Leader "Enabling Users"
Werdstrasse 2, P.O. Box, 8021 Zurich, Switzerland
phone +41 44 268 15 05, direct +41 44 268 15 64
lukas.haemmerle at switch.ch, http://www.switch.ch