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