(Christian Gasser)
One of the issue we’ve encountered in eGovernment that we have a user with an account with an IDP and that user has a set of roles, role x role y and so on and there is a bunch of SPs. This is pretty basic stuff. A classical way to do it is that when the user logs in the info goes to the SP, the user can choose the role, what a user is accessing another SP he will have to do the same. Are you acting as a dentist or as a doctor? you have to log that. You won’t get a full set of roles belonging to this role. If you are nurse I am still a nurse to other SPs. In some cases, we had a national IDP and each user can act both as citizens and employees and different credentials for different SPs don’t want to know the whole list of roles, do we let the user choose the IDP? We don’t want to make him login every time.
Peter: In a very simplified case what you can do with SAML and for chivl IDP those can also have values. So the SP can tell your IDP what value he is interested in. The IDP will then only send the filtered roles to the SP.
Christian: is that standard?
Peter: Yes. The range of values not. It can’t say I want faculty n. With severely constrained values. It already works. A simplified version exists in SAML.
Christian: But sometimes you need more roles.
Peter: Of course, you can implement the policy. The SP can tell you what you agree on the attribute names. That’s just making the policy distributed and runtime configurable.
Mads: we don’t have this communication in the metadata for specific values, if it’s too specific, what we want to do is to have a possibility to put it into the metadata. Some kind of traffic suffix.
Peter: It’s irrelevant but let’s drive the configuration, don’t make the SP show roles that are not relevant, filter it before you send it to the IDP. The IDP should have a way to know what is important. That narrows down the choices, but it still leaves you with those that could possibly be used for the SP. Who would know at this time she wasn’t a nurse at this time?
Meds: what would other IDPs if this is how you do it. They don’t have the values in them. We need a generalized way to put this into the SAML metadata for values.
Chris: You also have to modify the value. There would be one number of the organisation and a name. We could actually do that.
Peter: You need everyone to agree on consistent use.
I understood that I all of the roles are sent to the SP. Dont send everything to anyone. Model your attributes, that’s one way we can do it. When you authenticate the IDP I will choose I am a nurse as a role and here I am the role of doctor.
Peter: This is why it’s a bad model. Christian: What could you do? You can’t do anything else. P: It’s not inconceivable to have an SSO, have this thing for a set of attributes. C: You have to signal the IDP you want to change your role, right? Peter Pichler: If you say I am interested in nurse and doctor one approach is to send this be both and make the selection if the person acts as a doctor or nurse in the service itself. We have different situation with roles but we always send all the roles for one application which use case you want to use and I think this is not a bad solution to make it. Peter: Do we gain or lose more by moving everything to the idp? There is no clear advantage. Mads: then you have one place of setting the role. This is what we call a main role. A principle role. We should just put a bit of Danish context into it. We have this state ID which is always used as an employee ID, if you are a doctor you can have a lot of these cards. If you are a doctor you have 5-8 of these cards (OTP cards). What they want to do is a credential they have to choose which credential they want to use. TO make it easier for the user but then they have to choose the main role at some other time. Instead of having a folder with 20 card. You have some kind of a list. My idea is if we do that for IDP that knows all this then all SPs should be specially for role selection, if you want to change it you should be sent back to IDP. In this case I want to be this one and if its a smart SP it might know you have two roles but a dumb one would overwrite the old role. The complexity in the UI should be on the same place in the IDP.
Peter: SP wouldn’t need to do anything, make the IDP clever, I can offer you those roles from which SP you come from so you can still filter down the roles. The authentication for the IDP is in the context for the IDP.
C: Sometimes when you want to signalize it, you have your IDP session you can always ask for it to be reauthenticated. If you set another authentication request it can prompt you to a switching a role.
P: If the SP wants to login again with a higher accessing it would ask the IDP for that and it could use another factor. Sometimes the SP would demand a higher QoA but it could also be the IDP that access a policy. You would have to authenticate with a second factor. The policy can be done with SP or IDP and you can keep the SPs simpler. C: You could do something to switch roles. P:SP is stupid in this way and if you login again no other IDP it just replaces everything you had. if you rely on the session itself you cannot have more than one: For some applications it might be something that you want. C: How can you signal your authentication request whether you want to reauthenticate or choose an a new context? you want something different to happen? In some cases you want to reauthenticate. P: Then you make a forced authentication. C: Otherwise you send a request and let the user choose. You switched ole in one SP but you still have the old role in another SP. M: The current suggestion in Denmark is that you log out of everything and then change your role, suddenly you have to log in again. C: On the other hand you always have one role in your SP if you switch a role. P: it all depends how far the IDP is from the SP. why wouldn’t you want to be a doctor in one and nurse in another? If those are in separate domains the only place where a person can pick up a role, I need to act in this role right now. The person needs to choose a specific SP. Unless your roles are such that the role is intended to apply to these SPs. PP: Is this a practical signature? Are there user interfaces to select roles? Or a mesh federation but have different IDPs? How do you imagining such functionalities? The IDP is the wrong point to select these roles. P: technically it depends on the deployment. This is hospital in denmark its constrained. PP: specially build for one use case or? P: For IDP there is nothing special. There are intercept flows and those modify what goes out. PP: Do you have an UI? P: You can add it without much programming PP: From my POV it would be more practical to say an SP has a set of roles, he gets them all together at once and he has to handle it in some way. M: In Denmark this is a list that applies to federation technologies but there is one government IDP that uses SAML for everyone. Today I will be doctor x from this hospital and tomorrow a nurse x from another hospital. We cant get rid of selection of roles. You have multiple roles. PP: We differentiate it between accounts and roles. If you have two hospitals then two accounts. P: In Denmark is the same IDP.
C: We want to have more IDPs too, but they would be all behind one proxy. P: Once you have it it has this draw to move everything to a centralized place. In our world, we would have the SP do the work and not the IDP. The SP is the one that cares. In our world, you move the work to those needed. M: It wouldn’t be in the middle we have this Danish ID and if you have 20 IDPs they would use that for their authentication. There is not one in the middle, one in the back that we use for authentication. P: its selecting the place you want to authenticate and that determines the roles. M: Let’s say one hospital has one IDp but you can be on two roles in the hospital. P: you have a two step selection. What are the roles from one and what from the other?
C: Another thing that we discussed in the next gen the government id would want to consolidate. Especially lawyers and accountants that would work for different companies. We were trying to consolidate, one set of credentials but still another way to address it we don’t send all roles to SP so in some cases you can still have your separate accounts, if you do something sensitive in a party or something with your sexual orientation. It’s not your role but it’s your party that is sensitive. You could have your own account.
This sensitive information thing for political parties in europe being sensitive comes from the second world war where they could get all sexual orientation and political information and used that for war.
P: You could distribute the config files to the software. If there is a published standard I would also prefer that one. M: We can’t have a mechanism in the metadata so we have to find a way to do it in metadata without making it as complex as a siv configuration. There is only a very specific list of explicit values. PP: it’s not possible to use attributes? P: there is nothing that says that string is a regex. It’s an element with c data in the middle but the specs don’t say it’s nothing but a string. PP: But you can’t request some specific scopes like in Vienna, this would be interesting. P: We have what we have and we move to openID. Committee specs like stuff that was published since SAML 2 was released in 2005. Something that will never happen. Based on the editor of the specifications. You could always have extensions. There is no legal way to do it in SAML metadata, you can always do it like this. A more elegant way of doing this. We want standard if we don’t do it in a standardized way we won’t be too popular about this. In this case the SP doesn’t have to care about it. And draw in the problems of the SPs seems to be a good idea in some cases.
What about delegation? That this lawyer can act as me and when we go to the SP we only want to show the one that is delegated but not an entire list. That’s also related to roles. We have this module attached to the government IDP. How do you send this OK to ISP?
PP: I would send one representation with a use case, always specs few implementations. Which mandate should be used and make a selection without making a login. A portal for companies you need to relog. C: You do it at the IDP then? PP: In this case yes. Different roles or in several cases a selection of IDPs. P: In theory it’s the same thing but a much more sensitive. The SP sees only user b as you say you are user b. You could still have an attribute saying that. The question is do you need extra signalling? I think you need this information. Sounds like a security nightmare. The other point is when making another role changes this opinion. Otherwise you get role confusion.
PP - Peter Pichler
