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

[SSO] Add initial SSO integration #176

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

mandarl
Copy link
Contributor

@mandarl mandarl commented Mar 2, 2024

  • Entry point is a link on the login page. We can style it as button later.

  • This redirects to the dev mode keycloak container. The browser url is http://keycloak:8080 so devs need to add local DNS entry that redirects keycloak to 127.0.0.1. I couldn't figure out a way to avoid this. The keycloak container uses the openldap container as it's datasource.

  • On successful login we are redirected back to calendar. I have added a couple of useful links in the account menu.

@mandarl mandarl force-pushed the feature/sso branch 2 times, most recently from a7906ed to b33d959 Compare March 16, 2024 17:08
@@ -101,6 +109,8 @@ services:
- db
ports:
- "8000:80"
extra_hosts:
- "host.docker.internal:host-gateway"
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is to ensure that xdebug can connect inside docker instance.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Makes sense to me.

{
private $oidc;

public function __construct()
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This should probably be a singleton. But that will mean we will have to be careful about switching access tokens for users. This will work for now.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you provide a scenario where this would break in our current environment using our current procedures? How would we change those to 'be more careful'?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It doesn't break anything but has different trade-offs:

Per session instance (as implemented in this PR):
This implementation means that there is a separate instance of OpenIDConnectService for every logged in user. Each of these instances will call the .well-known url (https://login.dallasmakerspace.org/auth/realms/DMS/.well-known/openid-configuration) on keycloak to get config.

Singleton approach:
If we switch to singleton then there will be one instance for the whole application. We would avoid the call to get config for each user. However, we would need to maintain a map of access tokens for each user. Whenever we fetch groups for a user we have to set that user's access token on the oidc client.

Conclusion:
Singleton is too much of a hassle to implement without much benefit.

Copy link

@zphelj zphelj left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks OK to me though my SSO experience is limited and my PHP is rusty!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants