<div style="font-family: arial, helvetica, sans-serif; font-size: 10pt; color: #000000;">Hi,</div>
<div style="font-family: arial, helvetica, sans-serif; font-size: 10pt; color: #000000;"> </div>
<div style="font-family: arial, helvetica, sans-serif; font-size: 10pt; color: #000000;">Thank you for your answer.</div>
<div style="font-family: arial, helvetica, sans-serif; font-size: 10pt; color: #000000;"> </div>
<div style="font-family: arial, helvetica, sans-serif; font-size: 10pt; color: #000000;">So for now I will use the ComputeId way and we will see ...</div>
<div style="font-family: arial, helvetica, sans-serif; font-size: 10pt; color: #000000;"> </div>
<div style="font-family: arial, helvetica, sans-serif; font-size: 10pt; color: #000000;">I have enabled the persistent NameID generation in "saml-nameid" and reused the deprecated syntax to have the generated NameID as "eduPersonTargetedID", and also a scoped version as "pairwise-id".</div>
<div style="font-family: arial, helvetica, sans-serif; font-size: 10pt; color: #000000;"> </div>
<div style="font-family: arial, helvetica, sans-serif; font-size: 10pt; color: #000000;"><AttributeDefinition id="eduPersonTargetedID" xsi:type="SAML2NameID"<br />nameIdFormat="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent"><br /><InputDataConnector ref="computed" attributeNames="computedId"/><br /><AttributeEncoder xsi:type="SAML2XMLObject" name="urn:oid:1.3.6.1.4.1.5923.1.1.1.10" friendlyName="eduPersonTargetedID" /><br /></AttributeDefinition></div>
<div> </div>
<div>The only thing I can't undersand for now is how to have a persistent NameID in the SAML assertions. If the SAML2PersistentGenerator only is enabled, there is even no subject. But if SAML2TransientGenerator or both are enabled, I have a "<saml2:NameID Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient" ...".</div>
<div>Here I found useful informations : <a href="https://www-public.imtbs-tsp.eu/~procacci/dok/doku.php?id=docpublic:systemes:persistentnameid">https://www-public.imtbs-tsp.eu/~procacci/dok/doku.php?id=docpublic:systemes:persistentnameid</a> and the subject contains a persistent NameID.</div>
<div> </div>
<div>Is there something else to configure or is is only depending on the SP's request ?</div>
<div> </div>
<div>And thanks for reminding me to check raw SAML stuff in your other reply, and not only aacli text output !</div>
<div> </div>
<div>Regards</div>
<div><br /><br />Le 04-Nov-2022 15:19:42 +0100, users@shibboleth.net a écrit:</div>
<blockquote style="margin-left: 0; padding-left: 5px; border-left: 2px solid #000080;">* spf via users <<a href="mailto:users@shibboleth.net" target="_blank" rel="noreferrer noopener">users@shibboleth.net</a>> [2022-11-04 14:37]:<br />> As I was asked to provide high availability too, I need to use some<br />> kind of clustered database. Then I had the idea to try something<br />> else than MariaDB, say Rqlite we recently heard good things about<br />> from our devs. But no JDBC driver is provided, so I was trying to<br />> figure out if I could use another kind of DataSource.<br /><br />I suspected rqlite was the reason for that question. ;)<br />While there's some basic Java code unfortunately noone has contributed<br />JDBC support yet, <a href="https://github.com/rqlite/rqlite-java/issues/15" target="_blank" rel="noreferrer noopener">https://github.com/rqlite/rqlite-java/issues/15</a> <br /><br />> As far I can see, some mechansime was setup to provide an<br />> "eduPersonTargetedID" attribute as persistentID, but I have no clues<br />> about any NameID.<br /><br />A NameID of format "persistent" (section 8.3.7 in SAML Core, PDF p.86,<br /><a href="https://www.oasis-open.org/committees/download.php/56776/sstc-saml-core-errata-2.0-wd-07.pdf" target="_blank" rel="noreferrer noopener">https://www.oasis-open.org/committees/download.php/56776/sstc-saml-core-errata-2.0-wd-07.pdf</a>)<br />is what the (deprecated, see<br /><a href="https://wiki.refeds.org/display/STAN/eduPerson+2020-01#eduPerson202001-ChangeLog" target="_blank" rel="noreferrer noopener">https://wiki.refeds.org/display/STAN/eduPerson+2020-01#eduPerson202001-ChangeLog</a>)<br />eduPersonTargetedID attribute requires for its value.<br /><br />Some SPs will be able to make use of "proper" persistent NameIDs,<br />i.e. those sent in the Subject element of the SAML Assertion (the<br />standard place since SAML 2.0 came out in 2005 CE) instead of as<br />attribute values of the eduPersonTargetedID attribute.<br />You'd configure support for those using conf/saml-nameid.properties<br />and conf/saml-nameid.xml<br /><br />> If I understand good, given a certain peer entity and a principal<br />> name, the algorithm behind ComputedIDs will always provide the same<br />> computed id if the salt is the same ?<br /><br />Yes. Though it's function is more clearly described by focussing on<br />the fact that for the same principal (and salt) the values will differ<br />for each peer entity. ;)<br /><br />> So maybe I have no need for a database stored persistentId ?<br /><br />That certainly works and many are using it that way. The only thing<br />you lose without a database is the ability to make "changes", e.g.:<br />Computed value xyz123 was a some point issued for subject A but<br />subject A is now identified by a different principal name B. Using a<br />database you could map previously asserted (output) values to a<br />different input value. I.e., even though the userid for the subject<br />changed the resulting NameID does not.<br />Or you could "expire" previously asserted values so that if the same<br />principal name comes along now a different/new value would be<br />generated, e.g. when the (input) principal name was recycled is now<br />being used by a different subject/person. You'd need to make sure then<br />that the same input still produces a different output, as SAML core<br />mandates that "A given value, once associated with a principal, MUST<br />NOT be assigned to a different principal at any time in the future.")<br /><br />Whether you actually *need* to support these use cases (re-mapping or<br />disabling of previously generated values) only you can know.<br />If you don't, well, you still need to decide whether or not you will<br />support thise going forward or not.<br /><br />> The support team of one of the federations we are linked to told me<br />> about two attributes which could be relevant in the future and I<br />> added the configuration for them<br /><br />Sure, those are the immediate (you can start using them right now) to<br />long-term (i.e., some services will take years to move over or will<br />never do) replacement for persistent NameIDs, eduPersonTargetedID,<br />eduPersonUniqueID and also (to some degree) eduPersonPrincipalName.<br /><br />Also note that both SubjectID and PairwiseID come with the same<br />non-reassignment requirement as persistent NameIDs (see quote above).<br />So if you're re-assigning "uid" (which you seem to be using as basis<br />for SubjectID) you already have no database to "fix" algorithmmic<br />mappings from (uid) input to (SubjectID) output value.<br />Probably that means you won't need one for persistent NameIDs /<br />eduPersonTargetedIDs, either!<br /><br />> Is it also possible to generate "eduPersonTargetedID" the same way<br />> (reusing the computed id) but with the same format as before, as a<br />> "EntityID!hPeerID!PersistentID" string ? I think this is what you<br />> call putting a NameID in an AttributeValue. Maybe it will not be<br />> useful in the future, but as some SPs I have seen in the federation<br />> require it, better provide it.<br /><br />Sure, e.g.:<br /><br /><!-- Deprecated persistent NameID wrapped in a deprecated SAML Attribute value --><br /><AttributeDefinition id="eduPersonTargetedID" xsi:type="SAML2NameID" nameIdFormat="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent"><br /><InputDataConnector ref="computed" attributeNames="computedId" /><br /></AttributeDefinition><br /><br />If you add this you'll also note the following warning in your logs:<br /><br />WARN [DEPRECATED:125] - xsi:type 'SAML2NameID', (file<br />[/opt/shibboleth-idp/conf/attribute-resolver.xml]): This will be<br />removed in the next major version of this software; replacement is (none)<br /><br />Also, your old configuration will likely have been using<br />BASE64-encoded values and your new configuration would have to match<br />this for persistent NameIDs/eduPersonTargetedID in order to keep all<br />values the same.<br />But for new deployments BASE32-encoding is recommended.<br /><br />So I'd suggest to define 2 different DataConnectors of type<br />ComputedId: Once with encoding="BASE64" (only to be used for your<br />legacy eduPersonTargetedID attribute support; you'd also set<br />idp.persistentId.encoding=BASE64 in conf/saml-nameid.properties if you<br />needed to support proper persistent NameIDs with those same old<br />values) and another one with encoding="BASE32" to be used as the basis<br />for your new PairwiseIDs.<br /><br />HTH,<br />-peter<br />-- <br />For Consortium Member technical support, see <a href="https://shibboleth.atlassian.net/wiki/x/ZYEpPw" target="_blank" rel="noreferrer noopener">https://shibboleth.atlassian.net/wiki/x/ZYEpPw</a><br />To unsubscribe from this list send an email to <a href="mailto:users-unsubscribe@shibboleth.net" target="_blank" rel="noreferrer noopener">users-unsubscribe@shibboleth.net</a></blockquote>
<br/><hr>FreeMail powered by <a href="https://mail.fr" target="_blank">mail.fr</a>