(Niels van Dijk)
Niels: There is a number of integrations. The coManage product allows you. I support research collaborations, they have a registration and through the proxy we inject the information through the surfaces. I am working in the Geant project where we can benefit in the improvements and I would like to explore what is going on and I was relieved some new things that were pretty helpful. Who is actually working actively on SATOSA? Please describe what you’re doing.
Rainer: I haven’t had the idea yet to look at SATOSA so this is a new case I would like to learn about.
Scott: I have a number of deployments and all are for research organisations and the one I am talking about is the CIlogin introduced. It has its own OIDC engine and for that I wrote a plugin that allows a person from a VO, its a plugin that allows them to provision OIDC clients, e.g. the attribute release policy for the particular RP. You can say why I want this claim value for a specie identifier. It’s already been useful I would like to introduce this plugin to work with SATOSA.
Niels: This is spot on what I want.
Martin: We call it attribute enrichment. We know something about the person that is coming in but we don’t want to transfer the details so I have to query the additional CO-specific attributes. Knowing that we know the same identifier for this user. I have to jump through hoops so I have to make an intelligent filter to make sure COManage receives original IdP attributes, but other SP’s don’t and only get COManage attributes.
Niels: You just described another pattern. In our case it’s the comanage instance and all others should be kept from receiving. That ultimately means that it means that the policy that is done by SATOSA needs to be fed from comanage. If you are configuring your clients, you would maybe want to set it in such a way so that the SaToSa can pick up. Or set the attribute policy. This is even more brute force, I would not give that to you, this is all you get from me. The notion would be that there are multiple services. In some policy scenarios, all policies would get the same attributes. So you would maybe want to restrict what it gets. There is always good reason to limit and with GPR that might be a very good argument.
Kristos: This is not just about attributes. SATOSA should be aware of that. It might have to increment some workflows, for example if an ISP requires an authentication, how do you handle this with comanage.
Niels: We would need to see what they would like to collect and they would have an impact on what SATOSA needs to do.
Scott: One more use case is that we have this pattern where the user comes through SATOSA, the most interesting time is when the user is not allowed access. We would want to send the user to some error page that can deal gracefully with this situation and the resolution is that want them to see an error page that shows information about them that comanage knows. Right now comanage doesn’t have any graceful ways of doing it. But frequently the user already logged in, or one could start an enrolment workflow in Coanage. I have a couple plugins that deal with this gracefully. Maybe these users never enrol into comanage, they have already hidden their IDP but if we send them to comanage overflow.
Niels: I was thinking you’re going in some other direction. What you are saying is that you’re using SATOSA as an identification. So that implies that there is some business _____ that gains… Where are these rules being stored currently? Anyone else?
Gerben: We are using a comanage for a non-web, where you can use identity management. To grant people access, it’s not much involved with SATOSA but once you’re in CoManage and provisioned directly to service provider, then you have access to command line tools.
Niels: Not wanting to do ISP or moonshot. I am struggling a bit with integration with SATOSA. There is def shared user cases, that the others are using it in different notions. How can we support non-web use cases? We have introduced SSH keys, we could do OTPs, you could do certificates there and the next question is do you let the user or leverage existing ones to automatically (e.g. via RCauth) inject this into comanage which smells a bit like organisational identity resources.
Kristos: I am not sure whether it’s completely straight-forward, by doing it via proxy. It’s one story to do it for the clients but another to do it for the proxy.
Niels: The current coManage allows you to import an LDAP. That probably doesn’t resolve all trust issues. Since Niels is from ARC there are these attributes that this requires.
Kristos: There should be a consensus how one is addressing the other. This directs the workflow. If we can have consensus because we do have these use cases.
Niels: The only way to hit the deal is if you hardcore the attribute authorities.
Scott: I think a lot of what they are thinking about doing is to have SATOSA operating in a different way. There is no way to make a change dynamically on the fly.
Niels: You can change the config file. However, that will only get you so far. If you want to have a hundred SAMLs, this would never work.
Scott: SaToSa needs a different config mechanism. So that you could do something else besides YAML files. There might a little resistance to changing the backend way but we will consider it.
Joannis: SaToSa should bend on files and ask for things and whether you use that database that should be up to you. Having a config being ready on every request.
Kristos: You could signal this or taking it.
Scott: I could write a coManage plugin.
Niels: It’s allowed to receive information so on the fly it could be able to do authentication to watch the RP. Same for SAML.
Kristos: I am very ignorant about SATOSA. One use case is the user tries to access a service, he is not registered so that he must through an alternate flow. Even though the user has already authenticated and passed the proxy and it doesn’t work, where the user is sent back to proxy with SATOSA, SATOSA directly uses the discovery service. You said something that hit me this is the design of SATOSA. Does it support SSO at the IDP interface?
Scott: It doesn’t do that. If you are in the middle of a single-sign in flow, and you stop you would need to do it from the start again.
Kristos: I didn’t expect that the user would have to go through the discovery process from the start.
Scott: Sessions are brief so when the session is done it’s discarded.
Kristos: The user must select the IDP twice in the same session, it leads to a broken process. Even it was like this because of design the user experience is bad. This is a problem, a UX problem. The case that we are discussing is not changing.
Benn: We should set up a discussion list where we can discuss topics that do not belong to either SATOSA or COmanage, but clearly needs to be discussed.
