~Re: Storing persistentId using an HTTP DataConnector

[spfma.tech at e.mail.fr]

Hi,   Thanks for your answer.   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.   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. 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. Of course, it includes dumb things until I understand they are :-)   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.   Then I was able to setup CAS integration.   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).   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. But no JDBC driver is provided, so I was trying to figure out if I could use another kind of DataSource.   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. So this point is now invalid, if I go this way I will have to use a database featuring JDBC drivers.    As far I can see, some mechansime was setup to provide an "eduPersonTargetedID" attribute as persistentID, but I have no clues about any NameID.   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 ? So maybe I have no need for a database stored persistentId ?   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 :    

   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. Maybe it will not be useful in the future, but as some SPs I have seen in the federation require it, better provide it.   Regards

Le 28-Oct-2022 17:43:20 +0200, cantor.2 at osu.edu a crit: 
> Hi, Of course it's only a part of the process.

What process? If you don't explain what your goal even is, it's hard to say what is or isn't possible.

> I am migrating an IdP3, and in our running legacy installation we have : 

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.

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.

> According to what I have read here...

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.

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).

-- Scott

-------------------------------------------------------------------------------------------------
FreeMail powered by mail.fr
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20221104/3023d648/attachment.htm>