-
Notifications
You must be signed in to change notification settings - Fork 20
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
base: master
Are you sure you want to change the base?
Conversation
a7906ed
to
b33d959
Compare
@@ -101,6 +109,8 @@ services: | |||
- db | |||
ports: | |||
- "8000:80" | |||
extra_hosts: | |||
- "host.docker.internal:host-gateway" |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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() |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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'?
There was a problem hiding this comment.
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.
There was a problem hiding this 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!
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.