<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Hi Scott,<div class="">Thanks for your explanation, it helped.</div><div class=""><br class=""></div><div class="">Maja</div><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">Wiadomość napisana przez Cantor, Scott <<a href="mailto:cantor.2@osu.edu" class="">cantor.2@osu.edu</a>> w dniu 16 lut 2015, o godz. 16:03:</div><br class="Apple-interchange-newline"><div class="">On 2/16/15, 9:41 AM, "Maja Wolniewicz" <<a href="mailto:mgw@umk.pl" class="">mgw@umk.pl</a>> wrote:<br class=""><br class=""><blockquote type="cite" class="">I describe things in detail below, but the main issue is that both with <br class="">ComputedPersistentIdGeneraton and StoredPersistentIdGenerator I seem to <br class="">be forced additionally release idp.persistentId.sourceAttribute, which is <br class="">something I definitely do not want to do.<br class=""></blockquote><br class="">It's something you have to do, yes.<br class=""><br class=""><blockquote type="cite" class="">In consequence this attribute is sent to an SP.<br class=""></blockquote><br class="">Not unless you attach an AttributeEncoder to it. Don't do that.<br class=""><br class="">This is a cost of having the separation between the attribute machinery <br class="">and the NameID machinery, but I think your main complaint has to do with <br class="">how the database is keyed, see below.<br class=""><br class=""><blockquote type="cite" class=""><br class="">Using this strategy requires changing the idp.persistentId.strategy <br class="">property to "shibboleth.StoredPersistentIdGenerator" and setting the <br class="">idp.persistentId.store property to the name<br class=""><br class="">of a bean you must define. You can place it in saml-nameid.xml if you <br class="">like.<br class="">The main content of that bean is a reference to a JDBC DataSource object. <br class=""><br class="">First of all I suppose that there is a mistake in the documentation <br class="">because setting idp.persistentId.strategy seems not to be recognized, so <br class="">I set: idp.persistentId.generator=shibboleth.StoredPersistentIdGenerator<br class=""></blockquote><br class="">I'll take a look, but it would be best for you to file a bug on that so I <br class="">don't lose it. The attribute part is not a bug, it's by design.<br class=""><br class=""><blockquote type="cite" class="">The problem is that while using shibboleth.StoredPersistentIdGenerator I <br class="">still have to declare idp.persistentId.sourceAttribute and <br class="">idp.persistentId.salt and the worst - an attribute set<br class="">as idp.persistentId.sourceAttribute has to be released by a policy.<br class=""></blockquote><br class="">You don't need the salt unless you keep it configured with the option to <br class="">generate the first identifier compatibly with the computed strategy (that <br class="">was a feature in V2 and I had to carry it over). I don't have the <br class="">properties in front of me, but there's a way you can turn that off, but <br class="">that just eliminates the salt, which isn't really a big deal.<br class=""><br class="">The underlying attribute is needed because that gets stored in the <br class="">database as a key so that username changes don't affect the identifier.<br class=""><br class=""><blockquote type="cite" class=""><br class="">When attribute sources are provided, first PersistentSAML2NameIDGenerator <br class="">generates NameID from an attribute, then <br class="">StoredPersistentIdGenerationStrategy locates stored ID<br class="">which is sent as NameID. Reverting this process and skipping generation <br class="">from an attribute when StoredPersistentIdGenerationStrategy succeeded <br class="">would be better.<br class=""></blockquote><br class="">No, it's not. If we did that, the storage would be keyed by username, and <br class="">that tends to not be a stable identifier in most deployments.<br class=""><br class=""><blockquote type="cite" class="">Can I achieve it in some way?<br class=""></blockquote><br class="">Short of writing your own replacemnt plugins, which you certainly can do <br class="">if you choose, no.<br class=""><br class="">I'm also opposed to moving the filtering step after the NameID generation <br class="">step, because in the more general case where people are populating NameID <br class="">directly from an attribute, I don't want people to accidentally "release" <br class="">an attribute value in the NameID when they don't have a filter rule for <br class="">it. That use case is vastly more common (and useful) than persistentID use <br class="">is.<br class=""><br class="">-- Scott<br class=""><br class="">-- <br class="">To unsubscribe from this list send an email to <a href="mailto:users-unsubscribe@shibboleth.net" class="">users-unsubscribe@shibboleth.net</a><br class=""></div></blockquote></div><br class=""><div class="">
<div class="">-- <br class="">Maja Gorecka-Wolniewicz <a href="mailto:mgw@umk.pl" class="">mgw@umk.pl</a><br class="">Uczelniane Centrum Information & Communication<br class="">Informatyczne Technology Centre<br class="">Uniwersytet Mikolaja Kopernika Nicolaus Copernicus University<br class="">Coll. Maximum, pl. Rapackiego 1, 87-100 Torun, Poland<br class="">tel.: +48 56-611-27-40 fax: +48 56-622-18-50 tel. kom.: +48-693032574</div>
</div>
<br class=""></div></body></html>