persistentId in IdP 3

Maja Wolniewicz mgw at umk.pl
Mon Feb 16 04:41:24 EST 2015


Hi,

While playing with Shibboleth IdP v.3 I found some problems with 
persistent identifier generation.
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.

So the details:
The default strategy (shibboleth.ComputedPersistentIdGeneraton) seems to 
work as expected but what worries me - an attribute set as 
idp.persistentId.sourceAttribute has to be
released by a policy otherwise it cannot be used as a key for the 
subject and NameID generation fails.
In consequence this attribute is sent to an SP.
I observe a similar problem with the persistent store.
I followed this instruction 
https://wiki.shibboleth.net/confluence/display/IDP30/NameIDGenerationConfiguration#NameIDGenerationConfiguration-PersistentIdentifierGeneration 


/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
idp.persistentId.store=UMKStore
and I add UMKStore bean.
It works and even when persistentId is changed in the store, the new 
value is added to saml2:Subject.
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.
According to the log when profile AddNameIDToSubjects is proceeded and 
request specified urn:oasis:names:tc:SAML:2.0:nameid-format:persistent 
format first PersistentSAML2NameIDGenerator is used and when attribute 
sources did not produce a usable source identifier then an error event 
is sent (InvalidNameIDPolicy).
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.
Can I achieve it in some way?

Maja

-- 
Maja Gorecka-Wolniewicz          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/cafd4cfb/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5278 bytes
Desc: Kryptograficzna sygnatura S/MIME
Url : http://shibboleth.net/pipermail/users/attachments/20150216/cafd4cfb/attachment.bin 


More information about the users mailing list