persistentId in IdP 3

[Maja Wolniewicz]

Hi Scott,
Thanks for your explanation, it helped.

Maja

> Wiadomość napisana przez Cantor, Scott <cantor.2 at osu.edu> w dniu 16 lut 2015, o godz. 16:03:
> 
> On 2/16/15, 9:41 AM, "Maja Wolniewicz" <mgw at umk.pl> wrote:
> 
>> I describe things in detail below, but the main issue is that both with 
>> ComputedPersistentIdGeneraton and StoredPersistentIdGenerator I seem to 
>> be forced additionally release idp.persistentId.sourceAttribute, which is 
>> something I definitely do not want to do.
> 
> It's something you have to do, yes.
> 
>> In consequence this attribute is sent to an SP.
> 
> Not unless you attach an AttributeEncoder to it. Don't do that.
> 
> This is a cost of having the separation between the attribute machinery 
> and the NameID machinery, but I think your main complaint has to do with 
> how the database is keyed, see below.
> 
>> 
>> Using this strategy requires changing the idp.persistentId.strategy 
>> property to "shibboleth.StoredPersistentIdGenerator" and setting the 
>> idp.persistentId.store property to the name
>> 
>> of a bean you must define. You can place it in saml-nameid.xml if you 
>> like.
>> The main content of that bean is a reference to a JDBC DataSource object. 
>> 
>> First of all I suppose that there is a mistake in the documentation 
>> because setting idp.persistentId.strategy seems not to be recognized, so 
>> I set: idp.persistentId.generator=shibboleth.StoredPersistentIdGenerator
> 
> I'll take a look, but it would be best for you to file a bug on that so I 
> don't lose it. The attribute part is not a bug, it's by design.
> 
>> The problem is that while using shibboleth.StoredPersistentIdGenerator I 
>> still have to declare idp.persistentId.sourceAttribute and 
>> idp.persistentId.salt and the worst - an attribute set
>> as idp.persistentId.sourceAttribute has to be released by a policy.
> 
> You don't need the salt unless you keep it configured with the option to 
> generate the first identifier compatibly with the computed strategy (that 
> was a feature in V2 and I had to carry it over). I don't have the 
> properties in front of me, but there's a way you can turn that off, but 
> that just eliminates the salt, which isn't really a big deal.
> 
> The underlying attribute is needed because that gets stored in the 
> database as a key so that username changes don't affect the identifier.
> 
>> 
>> When attribute sources are provided, first PersistentSAML2NameIDGenerator 
>> generates NameID from an attribute, then 
>> StoredPersistentIdGenerationStrategy locates stored ID
>> which is sent as NameID. Reverting this process and skipping generation 
>> from an attribute when StoredPersistentIdGenerationStrategy succeeded 
>> would be better.
> 
> No, it's not. If we did that, the storage would be keyed by username, and 
> that tends to not be a stable identifier in most deployments.
> 
>> Can I achieve it in some way?
> 
> Short of writing your own replacemnt plugins, which you certainly can do 
> if you choose, no.
> 
> I'm also opposed to moving the filtering step after the NameID generation 
> step, because in the more general case where people are populating NameID 
> directly from an attribute, I don't want people to accidentally "release" 
> an attribute value in the NameID when they don't have a filter rule for 
> it. That use case is vastly more common (and useful) than persistentID use 
> is.
> 
> -- Scott
> 
> -- 
> To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net

-- 
Maja Gorecka-Wolniewicz            mgw at umk.pl <mailto:mgw at umk.pl>
Uczelniane Centrum                     Information & Communication
Informatyczne                               Technology Centre
Uniwersytet Mikolaja Kopernika   Nicolaus Copernicus University
Coll. Maximum, pl. Rapackiego 1, 87-100 Torun, Poland
tel.: +48 56-611-27-40 fax: +48 56-622-18-50 tel. kom.: +48-693032574

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://shibboleth.net/pipermail/users/attachments/20150216/3c4d85b2/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5168 bytes
Desc: not available
Url : http://shibboleth.net/pipermail/users/attachments/20150216/3c4d85b2/attachment-0001.bin