(Niels van Dijk)
SP would update metadata, typically federation A would check this metadata and periodically update the metadata, eduGain update the metadata on federation B, entity below federation B, IDP would update the metadata then. if this is done once a night, that would add a minimum 5 days before it changes from fed A to fed B
If the update needs time to be done, the worse case scenario is up to 10 days. Ultimately before change percolates, that’s really bad, in 10 days that could lead to breakage or security breach, We would like to have a better way of dealing with this. One proposition is to use Websub.
Imagine a blog. It has a publisher, a hub and a subscriber, the entity that will take care of the notification that something has changed. Websub is a w3c protocol, a pretty small one. It requires for the publisher to not publish the HTTP page but it mandates that in the headers you add two additional elements, a self URL and hub URL, self is what points to the document itself and the hub URL is a notification to the subscriber where the sub can learn about the changes of the page that is being published. Typically, it points to a hub.
Originally I thought eduGain is a proxy in that case?
eduGain is not a proxy. A telephone book where you can loo up entities and has some guarantee that the entities are correct.
Why are you talking about a big XML document?
You could proc updates but how you do that is what we will find out here. You need to establish a mechanism to do that and to not break the trust chain.
What is the workaround for eduGain to publish its refresh rates, synched up to a degree, maybe there would be a sync mismatch?
N: Broadly said, that will be an improvement of the current situation. With very few technical requirements.
To inform when we are syncing. Metadata files tend to grow most of the time it would be doing work for nothing for each sync.
Why not use https? It would propagate quickly. There are ways to process XML files quickly, I showed it yesterday in my session (mads)
N: we have a working implementation in pyff. There are 4 considerations:
one of the challenges is that this model would add a lot of subscriptions. Most of these don’t change on a daily weekly basis, and 70x 6000 entities, any database can deal with that data, it’s a small number. One of the biggest issues that we encountered is to have deleted entities. In websub model, out of band, how the publisher tells the sub that there is a new subscription. There is an out of band mechanism, it’s assumed that the subscriber will magically know that there is content here.
The standard saml specs set a policy, but if I put a number in there, I don’t have to respect it.
David: We had this incident a couple of years back. As an SP I feel it’s my right to return this to myself, whether I accept an IDP or not. Federations fix themselves after a couple of days, so the cache duration number is ignored.
Edugain has a 6 hours cache duration as a federation. Worst case scenario, it will be 30 hours off.
Trust establishment – we felt that whatever we use here, the mechanism by itself should not be set around metadata. It should provide notifications about the changes but not to send the metadata changes themselves. That also means that you have to update all saml software globally to update the mechanism.
Scenarios - how does a fed notify eduGain of new metadata and in the second part we will look at how the downstream process would work. Ustream we want to be as compatible as possible. The simple scenario is you take out federation a to eduGain line, it goes to the metadata and pulls it up. We could introduce a web group, a very simple api call.
Downstream, it makes sense, you do want to be able to notify about the changes in a standardized way. You could publish a metadata flat-file with self and the hub links in the header and that would allow the fed to subscribe to the file, it would inform the federation of the change in the eduGain metadata. We get frequent updates when there’s a real change, accurate updates on the side of fed b. better is to use an MDQ if you’re eduGain.
Introduce a hint in the message, that would make the fed processing would no longer process a huge file but update specific entities in the metadata.
Finally, not publish for the whole of edugain but have individual entities. Technically speakings its possible, sub to entities that you’re interested in. Reduces traffic amount as well.
