Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Security - Authentication & Authorization #5

Open
anthonysena opened this issue Apr 1, 2024 · 3 comments
Open

Security - Authentication & Authorization #5

anthonysena opened this issue Apr 1, 2024 · 3 comments
Labels
roadmap Items for Atlas/WebAPI 3.x

Comments

@anthonysena
Copy link
Contributor

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:

  • LDAP
  • AD
  • Kerberos
  • OpenID
  • CAS
  • OAuth (version 2?)
  • IAP

Useful resources:

@anthonysena anthonysena added the roadmap Items for Atlas/WebAPI 3.x label Apr 1, 2024
@anthonysena
Copy link
Contributor Author

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

@fdefalco
Copy link

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.

@anthonysena
Copy link
Contributor Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
roadmap Items for Atlas/WebAPI 3.x
Projects
Status: No status
Development

No branches or pull requests

2 participants