persistentId in IdP 3

[Cantor, Scott]

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