David: Applications that come in and out of the system as they are being tried - SSO and different set of roles and authorization required associated to these roles There is a gitlab instance with certain projects where certain users have access to. On one hand there are organizational groups and on the other hand applications with their own set of roles Goal: to make a collaborative platform where in a standardized a way the federation will be notified about the set of roles supported
Just in time concept: civil society people logging in via different federated services - gitlab login - looking to join a certain project The goal is trying to associate different roles to different users
Matthew: CoManage is our framework in use, research projects in coManage are thought of as virtual organizations. It allows to manage group memberships, exposes a list of users into a LDAP directory and helps with the mapping. We deal with totally federated identities though, we do not have an in-house database for identities
David: CoManage would be adaptable in the just in case scenario then
M: Within the AARC project a number of pilots have been done also with coManage. This domain problem connects to every research infrastructure at its core. There are also alternatives to coManage:
Perun, Hexaa, Unity, INDIGO IAM, MidPoint
AARC pilots here: https://wiki.geant.org/display/AARC/AARC+Pilots
SCIM: implementing provisioning is realistic but notifications will be complex Use SCIM to configure Schema
Check Google Schema implementation
Matthew: The mapping into the application is the hard part. The first step is getting IDs and groups of roles and mapping them together. The challenge is getting the web application to consume then this raw data. Share point is one of the easy cases. Authorizations can be built from existing membership data. The tool we use at NIH: redcap - it has an interface that looks at the remote user’s identity but without group memberships or authorizations. How do we get that? The application also has to support the technology, skim for example has to be plugged into the application itself.
Even if it is a closed environment you can put anytime of attribute or configure the proxy in your own way as long as it is understood by you and the app.
You provision it into the directory or just send the answer on the fly in saml – the difference is what can the application consume / is it saml aware or not . Most apps can rely on a ldap connection which is also easier than the saml configuration for the application
Matthew: sure but that requires software eng resources, which you don’t always have
David: I conceptually wanted to get away from ldap to make a virtual layer on it If we put it into saml we would use the saml tokens then
Choices > app by app decision and a preference order: App able to consume saml tokens – least work to do – preferred version App provisioning or writing call to an external directory
Matthew: In a harder scenario to make red cap work you write an additional plug in to access MySQL database of redcap and deprovision there in that instance
Matthew: Skim / would like to know any success stories to convince developers to switch to it – for example the dev of redcap? Is out of band provisioning the best option? There is no standard for the authorization data so maybe when the tech changes, i would go to the client and offer a standard set of attributes instead of letting them define their own SCIM is used to import data into wso2 If you are interfacing with Google you will have to use SCIM
SCIM has a very fixed schema for its implementation within Microsoft but it can be altered, customized.
Result: JIC Management with an IdM like CoManage / PErun Midpoint or others (see above) Create Roles for applications manually since there Applications hardly provide SCIM interfaces to query this Adding Basic SCIM Provisioning to Applications seems possible yet supporting the notification infrastructure will be a challenge Use SCIM to dynamically create the application specific Schemas If SCIM/SAML Attributes becomes unfeasible possibly fall back to LDAP to