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

Advanced Auth Features #2000

Closed
nabdelgadir opened this issue Nov 8, 2018 · 3 comments
Closed

Advanced Auth Features #2000

nabdelgadir opened this issue Nov 8, 2018 · 3 comments

Comments

@nabdelgadir
Copy link
Contributor

Description

Step 5 from #1035 (comment).

Armed with a small application having authentication and authorization constraints in place, let's look at extensibility and what extension points we may need to define to support those use cases.

Few example scenarios to drive our focus:

  • Allow customers to register and login using their Google account.
  • Implement multi-tenancy - group users and admins into realms. Users (customers and admins) from one realm cannot see data from other realms. A superuser can see data from all realms.
  • Simplify management of scopes by introducing Roles (a user belongs to a single role, a role grants many scopes).
  • Implement an OAuth provider for 3rd party client apps. Let the customer decide which scopes they are willing to grant to each app (an access token used by an app).
  • Add support for 2-factor authentication based on TOTP (Time-based One-time Password), using a mobile phone app like Authy or Google Authenticator as the second factor.

Ideally, there should be a documentation and/or a blog-post and/or a reference implementation to make it easier for LB4 users to implement similar functionality in their project.

Previous step: #1999

@David-Mulder
Copy link
Contributor

David-Mulder commented Nov 9, 2018

Just some real world feedback: A user might be able to "only read data (role: 'reader') from realm A", but also "can be an admin (role: 'admin') in realm B". So I would expect:

  • Realms can be nested (e.g. company -> department -> team)
  • A user can have one role for each realm he has access to

In combination with the nested behavior this would allow a user to have read access to all data from company A & C, but also have write privileges to department IV of company A.

@dhmlau dhmlau changed the title Next: Extension Points Advanced Auth Features Mar 1, 2019
@stale
Copy link

stale bot commented Feb 24, 2020

This issue has been marked stale because it has not seen activity within six months. If you believe this to be in error, please contact one of the code owners, listed in the CODEOWNERS file at the top-level of this repository. This issue will be closed within 30 days of being stale.

@stale stale bot added the stale label Feb 24, 2020
@stale
Copy link

stale bot commented Mar 26, 2020

This issue has been closed due to continued inactivity. Thank you for your understanding. If you believe this to be in error, please contact one of the code owners, listed in the CODEOWNERS file at the top-level of this repository.

@stale stale bot closed this as completed Mar 26, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants