persistentId in IdP 3
mgw at umk.pl
Mon Feb 16 15:13:59 EST 2015
Thanks for your explanation, it helped.
> 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
>> 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
> -- 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...
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 5168 bytes
Desc: not available
Url : http://shibboleth.net/pipermail/users/attachments/20150216/3c4d85b2/attachment-0001.bin
More information about the users