<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;">Thanks 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;">I am supposed to migrate an old IdP3 instance, and I am also trying to understand how things work and correct what is already mentioned as deprectated as much as possible.</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;">It has been setup a long time ago by someone else who has gone, and I am not sure everything is correct nor useful in the config files.</div>
<div style="font-family: arial, helvetica, sans-serif; font-size: 10pt; color: #000000;">As there is no documentation or notes about what has been done and why (or only links to the twilight zone), I am studying the whole thing in details and try to reproduce everything on Idp4.</div>
<div style="font-family: arial, helvetica, sans-serif; font-size: 10pt; color: #000000;">Of course, it includes dumb things until I understand they are :-)</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 applied the migration procedures (update to the last IdP3 version available, then update to IdP4) after correcting the attributes defintions and eventually managed to enable the AttributeRegistry.</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;">Then I was able to setup CAS integration.</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;">It seems not that bad so far, as the "hello" application returns the expected attributes values (except for the persistentId I had to comment out because the required database does not exist yet on my test instance).</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;">As I was asked to provide high availability too, I need to use some kind of clustered database. Then I had the idea to try something else than MariaDB, say Rqlite we recently heard good things about from our devs.
<div style="font-family: arial, helvetica, sans-serif; font-size: 10pt; color: #000000;">But no JDBC driver is provided, so I was trying to figure out if I could use another kind of DataSource.</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;">But I realized I have mixed up things between DataSources and Connectors. I was expecting some kind of REST client in lieu of JDBC, but HttpConnector is something else.</div>
<div style="font-family: arial, helvetica, sans-serif; font-size: 10pt; color: #000000;">So this point is now invalid, if I go this way I will have to use a database featuring JDBC drivers.</div>
<div style="font-family: arial, helvetica, sans-serif; font-size: 10pt; color: #000000;"> </div>
</div>
<div style="font-family: arial, helvetica, sans-serif; font-size: 10pt; color: #000000;">As far I can see, some mechansime was setup to provide an "eduPersonTargetedID" attribute as persistentID, but I have no clues about any NameID.</div>
<div style="font-family: arial, helvetica, sans-serif; font-size: 10pt; color: #000000;"> </div>
<div>If I understand good, given a certain peer entity and a principal name, the algorithm behind ComputedIDs will always provide the same computed id if the salt is the same ?</div>
<div>So maybe I have no need for a database stored persistentId ?</div>
<div> </div>
<div>The support team of one of the federations we are linked to told me about two attributes which could be relevant in the future and I added the configuration for them :</div>
<div> </div>
<div>
<div style="font-family: arial, helvetica,sans-serif; font-size: 10pt; color: #000000;"><AttributeDefinition xsi:type="Scoped" id="samlPairwiseID" scope="%{idp.scope}" ><br /><InputDataConnector ref="computed" attributeNames="computedId"/></div>
<div style="font-family: arial, helvetica,sans-serif; font-size: 10pt; color: #000000;"></AttributeDefinition></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 xsi:type="Scoped" id="samlSubjectID" scope="%{idp.scope}" ></div>
<div style="font-family: arial, helvetica,sans-serif; font-size: 10pt; color: #000000;"><InputAttributeDefinition ref="uid" /><br /></AttributeDefinition></div>
<div style="font-family: arial, helvetica,sans-serif; font-size: 10pt; color: #000000;"> </div>
Is it also possible to generate "eduPersonTargetedID" the same way (reusing the computed id) but with the same format as before, as a "EntityID!hPeerID!PersistentID" string ? I think this is what you call putting a NameID in an AttributeValue.</div>
<div>Maybe it will not be useful in the future, but as some SPs I have seen in the federation require it, better provide it.</div>
<div> </div>
<div>Regards<br /><br />Le 28-Oct-2022 17:43:20 +0200, cantor.2@osu.edu a écrit:</div>
<blockquote style="margin-left: 0; padding-left: 5px; border-left: 2px solid #000080;">> Hi, Of course it's only a part of the process.<br /><br />What process? If you don't explain what your goal even is, it's hard to say what is or isn't possible.<br /><br />> I am migrating an IdP3, and in our running legacy installation we have : <br /><br />Your only obvious problem is that you're using a deprecated attribute encoder that produces NameID values inside an Attribute. That ideally should be replaced with a persistent NameID generation strategy, which is a different thing entirely.<br /><br />But in terms of upgrading, you don't have to do much of anything, it's not going to break. If you upgrade of course. Upgrades are done in place.<br /><br />> According to what I have read here...<br /><br />That is for generating persistent NameIDs, i.e. NOT what you're currently doing. NameIDs and Attributes are not the same thing. Putting a NameID inside an AttributeValue is also not the same thing as generating a NameID in the assertion subject.<br /><br />If what you want to do is migrate to generating a NameID alone using the same values/strategy as before, you don't have to do anything more than get rid of the AttributeDefintion, and set a property appropriately so that persistent NameIDs will be based on the appropriate underlying IdPAttribute coming out of your StoredID connector ("persistentID" in your case).<br /><br />-- Scott<br /><br /><br /></blockquote>
                    <br/><hr>FreeMail powered by <a href="https://mail.fr" target="_blank">mail.fr</a>