(Mads Freek Petersen)
Takes care of everything SAML
Code is built on go libraries that we made. How does it work? it’s run locally.
Q: so the jwt is not a proxy by itself? A: how do you do the reflectin or the mirroring?
38 lines of SP code. It holds parameters and gets back to the saml IDP. Microservice creates a saml request and it calls again with a saml response and the service checks the response and checks the back and returns the jwt.
The IDP is simpler, test private key and name of the service, the payload is the attributes that you want to send and there’s an lt of sign in and you send it to the microservice and it’s signed by the hop, we sign it for the IDP, when it gets back to us, to check whether this is the actual IDP or from ourselves.
You should be able to run saml to jwt on the local side. you send out the jwt, the IDP.
You have to send the headers to the browser. It’s passing the stuff to the browser. The contents of the XML, you take what was sent back as post, forward that to the browser as well and it will post the service which will call into the microservice.
Who signs the authentication request/ response?
M: it is signed by the hop with our private key and sometimes we have signed responses ourselves. IDP signs the jwts. q: saml to jwt cannot do the signing. a: It’s signed by us and the hop’s private key. It comes in as a saml thing and we send it.
N: There is trust established but it’s not the exact same thing.
M: All of the trust is established by using stand up metadata.
The configuration is extremely simple.
Q: Is that an actual feature that you will provide? A: No because you are running everything locally.
JWT to saml requires a private key available. Locally you have control over the whole thing so you don’t need to sign it, the daemon should have access to your private key.
N: Why do this if there is oidc? M: Why oidc if saml is so easy?
It’s in gosaml. It’s available on Github.
It is a part of the great unified IDP. If you have mdq its easy to have the public key, that’s the only thing that you need.
Peter: if I want to create a new entity I fill up the entity id, create a key pair, enter it in your registry and that’s it?
How does saml know whom to trust? If you don’t have saml implementation, how do you do it? We look up metadata by its endpoints?
You sign it with the key(public key) and jwt is signed as well. We use metadata to check the key, we check whether it’s signed.
Because the idp is a member of the federation, it’s in the metadata.
You can run it in the same institute.
N: Why not let it send the encrypted blob?
M: Not only the attributes are encrypted and you need the private key to decrypt it.
N: The hub shouldn’t decrypt but you’d know the key. You’re taking care of the problem that I don’t want to deal with the saml but you decrypting is also important. Is it fair that saml was issued the correct?
You cant see the SAML yet, you first have to decrypt it.
M: We put all policy to metadata, it doesn’t know anything about entity categories. We try to make the problem simple and then metadata more complicated.
You can down the SP and run it in the data federation. the only sp allowed to access the open IDP is this one. You can’t cheat an sp to use what you just invented. You can run this on the Danish infrastructure.
Reference to the Great Unified IDP session.
Q: Can you modify the properties? Like the signing certificate?
Deploying an IDP for each scenario is impossible. IDP that you can control through an API.
Signing certificate can be screwed up, the TTL of the lifetime, give that to the proxy and the proxy can hopefully respond properly.
WAYF test service
If you’re an IDP you might want to check what is actually in there. If you don’t send a jwt you get some information. Looking at the SAML scoping, standardized way how to manage proxies.
How to route two proxies, we have 5 diff ways of doing it:
