The Grand Unified IdP

(Mads Freek Petersen)

• Present a project which has been worked on for some time.

Presentation: a project on Grand Unified IDP which started as Guest User IDP The Grand Unified IDP

• This is an attempt to make a micro IDP that manages its own guest users.
• Guest and Test users added to it
• Can be used as an IDP as a service The Problem: we tried to solve at the Technical University of Denmark that had a university-wide guest user database, but nobody had the responsibility of maintaining the users, there was no one who took care of the database. Guests need to behave in a specific way, a specific SP, if they don’t have a federated access (normal way through federated access) and then they have some guest users that don’t have federated access so then identity proof themselves and give them a new username and a password. · Guest logs in as a “SP” needed to be handled in a special way i.e. doing identity validation and store credentials · For the guests it is yet another username/password to remember The idea is to outsource the authenticator, what we call a backend IDP. This is only the authentication, so the back end IDP, which is a standard SAML IDP can be either one of the IDPs in the Federation, which doesn’t make much sense or it can be one big provider, where you can register yourself and be provided with a secured ID. The only thing the backend IP provides to the Grand Unified IDP is a pairwise ID. We let the SP handle the ID proofing, they had to contact the user and then the user gets access to the SP and they talk to the user and register the user. Then we create a token, which the SP sends to the user and this is where the ID proofing happens. When the token is delivered to the user, the SP needs to make sure it’s done in a way that fulfills the requirements for identity proofing. Then the user logs in via the token and then they have to choose a backend IDP to authenticate.
• Nothing about the user is known, because tomorrow it can be the same user as yesterday
• No personal information at the backend IP Then the SP can use federated identity for all its users.
• Problem: where are all the attributes stored?
• It’s up to the SP to decide. The interface between the user data and the SP, requests API when they log on using this entity/ID they registered in the first place. Then they send all of the information to the regular IDP, which then fit us according to the actual attributes that the SP assigned in the first place.

The presenter gives a demonstration of the registration of a new user in this scenario Q: Are you running everything on your machine? A: Yes, I am running everything on my machine… I can log in from other IDPs, but I can log in on other SPs because I don’t have the private key. · The other way to use it is for testing.

The presenter gives a demonstration of how to use the GUIDP for testing · It makes it very easy for a developer that doesn’t have access to IDP to make a specific SP on this machine. · Guest user IDP which can be used as test user IDP and also for IDP as a service.

Demonstrates running it on DeiC, instead of locally. · DeiC => Orphanage

Q: Where are you keeping the information? A: Currently we are using a system cookie, but we plan to use a permanent cookie. It needs to be accommodating, if you’re moving from one user to another. You can make account linking in it. Another thing, this is one SP and one database but the signup is made so that an SP can say to another SP “I want to trust you”, they have a small virtual communication where the SP becomes the IDP for another SP – a micro IDP. You can have many SPs trusting other SPs, that’s why you have to have the scoping in the usernames.

• We have a proxy behind this as well, but the main thing is that we have delegated the responsibility for the users to the SP.
• For SATOSA it’s the same, we use cookies to store the IDPs that the users have selected, basically what we have is the same as your project, but we use different terminology.
• I don’t see how it’s the same. We start by saying who is responsible for this specific SP users (the guest users). It is not outdelegated. I have an IDP which is my own so to speak and then we can build up from that, but from the start, what the SP sees from the grand unified SP is its own data.

Q: The SP receives the data of the user? A: No, it’s our own data. The SP is only responsible for maintaining the data.

Q: So, the Grand Unified IDP backchannels the SP? A: Yes.

Q: In order to query the SP, you have a key, right? Why are you doing this? A: Because it was decided to a virtual organization in the start. We start by making this very small something that the SP is responsible for its own users and it should have only one way of handling users. In the application, they might have another way of maintaining users, their own users into the database, but we don’t care about that. Every users comes with the same set of attributes.

• This is standard proxying.
• No, it’s standard SAML.

Q: The part I don’t understand is why the GUIDP queries the SP to get information, only to give the information back to the SP? A: In the isolated setting, it makes no sense. But in the other case, where the other SPs getting to trust the user database of this IP, does make sense.

• And it makes guests users and regulars users the same when they apply through the front door of the SP. Everybody comes in with the information that is needed to use this SP. In the case of the guest user that SP is responsible for itself, the app doesn’t have to be aware of the guest users at all. They all come in the same way through the federated doors. The reason why it doesn’t look in its own database is that when another SP wants to trust the 1st one as a micro IDP, it doesn’t have access to the same database. But the GUIDP has decided what access do we need to be able to send the information from the SP1 (micro IDP) to SP2, which is a new trust.

Q: How do you do this? A: The micro IdP has to say “I trust you as an SP” and then the other one has to say “I trust you as a micro IdP” and when they do that, you will be able to log in to SP2 with the data from SP1.

• The use case: we wanted to be able to say that there are two different services, but the responsibility is with the same organization of units.

Q: How is the trust developed? Do you select the people? A: The trusties are regular metadata, like in SAML. The only thing special here is that the SP initially gets its own data. And it gets all the other IDPs that are trusted in this Federation. The GUIDP is in the same Federation.

• We haven’t decided whether we will use existing IDPs or we are going to have 1 with a secure log into. There is no user validation at the backend IdP. it’s just about authentication on a high level, a secure level of authentication. I guess we would go with password-less authentication.
• You can also use existing IdPs

Q: What is the GUIDP? A: The Great Unified is a concept and an IdP.

• The backend IdP is only authentication, it doesn’t actually know the user.

Q: I want to select users that I trust. How can I know which are trustworthy and which aren’t? A: All users are coming from you, the users you get from the Great Unified IdP

Q: How is a key shared between the Grand Unified IDP and the SP? A: There is an invite for that. The SP creates the user in the database and gives them a principal name and then they register this name in the Grand Unified IDP and then sends them back a token, which is then delivered to the actual user in some way that is secure enough for the SP’s identity validation and the user then presents that to the Grand Unified IDP, you map the original EVPN to the excel from the backend IDP.

• It started working only yesterday locally, before that it was using database. We haven’t tried using it for other purposes yet.