(Mischa Sallé)
Mischa: The scenario is that there is a nice draft from Roland Hedberg on how to build am OpenID Connect federation and this is a generic scenario. You have many IDPs, and many SPs and they would have to cooperate with each other. Here we are interested in a subset of that: research- and e-infrastructures have all a proxy in the middle. You don’t have so many IDPs but only a small number of OPs. So the idea is to see if we can solve a subset of the federation spec where much more is feasible. There were ideas from David Groep and Jim Basney to do this, there has been some effort in IGTF, to get something running using some simple scripts but the questions is what are we missing there and what should we build?
David: are people familiar with the OIDCfed spec? (see https://openid.net/specs/openid-connect-federation-1_0.html)
Roland: If you look at the openID connect standard, if you have a relying party (RP) and an openid connect provider (OP), you start with learning about the OP, the RP sends the query and gets the provider information back and what might happen is that you do a dynamic registration https://openid.net/specs/openid-connect-discovery-1_0.html and you get a response back to that. This is the openID standard but if you look at this the RP sends information and the OP must trust it or not trust it. They don’t know who it is and the same goes for when the information is not certified. So if you have a third party on top of here that made you have some reason to trust it. What you want to do then is that you want to be able to construct this document that the OP returns when it’s asked for its provider information. That the OP can have the document. How you construct it is not specified in the draft so one of the things that appeared is the MDSS [Metadata Signing Service] so that the RP can send its metadata to this metadata signing service and it can sign a version of it which can then further on go to the OP. Is this metadata signing service and after that you can start running this. Of course there are pieces here if it’s something that happens over the net, it also has to know what policy to apply to that document before it signs it. Now depending on how much you want to have this less or more complicated, if the RPs are not more than 10 or 20 you can have them send it to you by email, you sign it and you send it back. There is no revocation service so the information you send has a lifetime and when we have discussed it, this the time would be pretty short - 15 minutes - but we really have to have this on the net. Like DNS. In another setting, maybe 15 minutes is too short, but maybe a day or even longer.
David: the other thing is the hierarchy in between the organisation and the RP.
Rainer: is that the authentication to the MDSS? If I was to have a PKI in place, for the RPs, what would be the best way to leverage this PKI?
You could use client-server verification, like SSL. If you have the common PKI that has the tickets David: you can do creative things here provided that you have to have the ultimate set of trust, and if you can authenticate the RP, https with certificate pinning. It does require you to have ultimate trust.
Roland(?): I would like to use Oauth or some access document.
Rainer: it just pushes the authentication problem. Any implementation on that that could be used? Using an existing certificate?
Roland: I have a very preliminary implementation of MDSS.
Wolfgang: As far as I know there is a pilot that’s supposed to be implemented in the Geant project (JRA3, Task 3.1) but they are going to use this. (cf. https://github.com/alejandro-perez/fedoidc/blob/multifederation/doc/howto/multifederation.md)
But the MDSS needs some policies and the main part of it. Isn’t it? Roland: What’s probably going to happen is that this RP sends the first time it sends using the http post, and some human would be watching it on the MDSS. But then it sets a template that if it’s the same data that needs to be newly signed, it would probably be automatic. MDSS would probably just check if something changed that it cares about and if not then the machine can probably do it.
Mischa: You want to use URLs? David: You would have to authenticate with a previous key or OAuth.
Martin: [concerning eduGain] Has it been locked into a big bag metadata assignment like we do with SAML? Why we couldn’t do it the same way like doing it in SAML? David: Why would we want a big bag of metadata if you are talking to a single target anyway?
It will never go up to the federation, everything happens locally. This is my guess as the most common pattern. Of course someone could be sitting at the federation.
Uros: How does that incident response happen? Do I go to a federation directly?
David: There are additional traceability elements.
Roland: Whoever sends the info, you could say that what they are sending is to take Peter’s view. About entities as such and a number of trust marks which are belonging to each federation and the federation appoints it to the policy of the federation, and when the other guy sends the response, it’s the data and the set of the federation it belongs to. It’s every possible federation you could use. This federation with this policy or the other one? We can’t manually evaluate policies but there are two sides to that. If I find something that I don’t approve of, there should be such information here. The other thing is when it comes to the incident is that if someone is misbehaving you want to get that person out and that happens by the information timing out. The longest time that anyone can be in the federation before someone can get them out is 15 minutes.
Marcus: The simple SAML federation link together many RPs together. Do you have a discovery or?
This is RA21 [https://ra21.org/] that is going to solve that problem. There are some twists to this. The RP that you are talking to may belong to 20 federations so you would have to choose the federation first and you as a user have no idea at all. The OP would have the same name or the same domain irrespectably to which federation they are connected to.
Mischa: The RPs in a proxy environment typically know the OP, approving all the RPs is much harder.
Roland: We are on the bleeding edge. This design have opened a lot of different boxes.
David: This decoupling trust of discovery will be a good thing because you can use federations. You don’t need entity categories you just get trust marks. Except suspension. Another federation has a test curation. Therefore I am going to check that.
Roland: That was the reasoning behind us having this discussion several weeks ago. EduGAIN was one, Sirtfi another, Ligo being the third. Who probably didn’t have a lot of policy by themselves. Maybe we wouldn’t enforce this crypto or client authentication.
Mischa: The Geant pilot is building what, signing service? Is it resigning?
Roland: You want to test this software in different RP libraries that we have like SATOSA. We can bring in our SAML world if we want to but we are sort of feeling the water here.
David: Will SaToSa have support for OIDC federation? We can take any existing service but a bit of satosa sauce around it and that’s good? It makes any SAML service into a RP which is federation capable.
Roland: I promised Rainer to have something running in March.
David: What more do we need? Has anyone look at takin the output of python scripts and tweaking the config file.
Roland: This is work for you.
Rainer: Also open ID models. But you could talk to him.
Roland: One way would be to make it static information from dynamic.
David: the role of federation operator would be different but probably more important as they are running multiple federations with more policies. They are fairly simply.
Roland: You are going to use for authentication. Are you also going to use this system for authorization.
David: IT would probably have many decisions, and these would be pushed to RPs. We say yes or no based on the attributes they get from the community.
Jim: That’s what we are trying to do with our tokens. Yes you have access to this data set and you are a member of this community which can be much easier clarified with the RP.
Roland: I guess this is where I have seen some people somewhere else than at the RPs side is within an organization like university like for instance a use case where you come to a service a proxy one and you authenticate and you get back an access token and then in a proxy service you choose from a set of services. That access token doesn’t contain information but they have to go to the OP and ask “What is this for”?
David: The other system that we have is different technology distributed authorization system called Argus based on XACML.
Rainer: How is the pickup? David: It’s used widely within narrow fields.
Mischa: What is the next step? Roland it’s to build MDSS, with OAuth.
Mischa: Inital token is delivered out of bound then.
Jim: I can use OAuth to say that I am a member. Roland: you have to leave some stuff out of scope because you will never get a licence.
Uros: Currently federations are legal entities. Is that a problem? David: InCommen is not Rainer: HO liberty document on trust, they have different models. Liberty Alliance.
Markus: The fact that it’s connected to an institute is not relevant.
