You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Adding in a note here to think about the authorization aspects of the security here. Specifically the work on a "read restricted" role as introduced by OHDSI/Atlas#2928 and even a team-based security later as described today on the ATLAS WG call by @pieterlukasse
Would also ask that support for multiple session tokens be possible. This would prevent the situation where logging into R and Atlas will log the other authentication out.
Linking OHDSI/WebAPI#2369 so we can think through the ideas around groups/teams and how this fits into the authorization layer of WebAPI. Ideas put forward from Atlas WG:
External identify provider declares groups/role membership which are mapped, by configuration, to groups/roles in WebAPI. This removes the complexity of mapping users directly to groups within WebAPI but instead maps them to higher level groups. Users are then assigned to a group by the identity provider making it the authority on this information.
Group membership within WebAPI will require different behavior: visibility and control over design assets that are shared within a group. We'll need to define the context where a user is working (i.e. a "workspace") and define the behavior associated with working within this context.
Do we want to move away from Shiro and use Spring for security?
What types of authentication mechanisms are required moving forward? Per https://github.com/OHDSI/WebAPI/wiki/Security-Configuration here is the list of currently supported authentication options:
Useful resources:
The text was updated successfully, but these errors were encountered: