I have an existing application that has JWT based authentication . Now I want to integrate ODK into my existing app . I want to use a common Identity Provider like Keycloak so that I can achieve SSO . Please help me in implementing this .
1 Like
hi @parthibd, and welcome. please be sure to introduce yourself if you have a chance and get to know some fellow odk users.
do you have any development experience? what you are asking to do will require a lot of coding.
1 Like
Hi @issa! I am Parthib from India. I was evaluating ODK and the need came up to integrate with an pre-existing app in my company. I was evaluating keycloak sso to get the job done. I was thinking since keycloak already has its own authentication and authorization system and so does our application can we use OIDC since they share the same emails in both applications. It won't require that much of effort as. Any suggestions?
the problem is that central already has its own authentication and authorization, which you would have to replace in order to use an SSO type solution.
replacing central's authentication is a large task; you'll want to look at how sessions are parsed in lib/http/preprocessors.js, and maybe lib/resources/sessions.js.
replacing central's authorization is probably a bad idea. it's woven through the code quite tightly.
@issa I do understand what you are saying but I am not looking to make major change or even replace auth system . Is there any way it can be achieved with minimal changes such that the core auth system remain more or less intact ?
I have an idea. Say I first authenticate with the SSO . I get my JWT . Then I pass my JWT to the /session endpoint with a POST . The controller method extracts the JWT ,verifies the signature and checks if the email in the JWT payload exists . If it does, it returns the token as any normal POST to /session would and sets the cookies . The important part here is that with the SSO JWT token , I do not need to verify the password , just that the email exists in ODK Central . Do you think it would work ? I would love your suggestion @issa .
3 Likes
I'm not qualified to comment on implementation details, just wanted so say that this is an awesome idea!
This is how we incorporate our SSO into legacy apps. Our proxy redirects to SSO, on successful return sets a session cookie (contains email), and apps check for existing users with that email and log them in. Sounds very similar to your approach with JWT.
2 Likes
Thank you for the inpur @Florian_May 
I am deciding to go on this path to implement SSO with ODK central as reworking the entire authN and authZ of DK central is not a viable option . @issa Any suggestions?
it's probably the best approach but it still won't be easy, and you will likely have ongoing pains keeping the changes up to date as we evolve the server.
you will need to have some way of:
on new account: validate the token, determine that a Central account does not yet exist, and create one. an email address will be necessary.
on login: validate the token, and generate a session for the user.
in general: remove all ui to do with account management, passwords, etc.
SSO with OIDC identity providers is now available in Central! See the documentation for details. It works much like described above: Central accounts get matched to accounts on the identity provider by email. Currently, Central accounts have to exist already so they can be assigned roles/projects. Eventually we intend to make it possible to assign default roles/projects and/or specify rules for using information from the identity provider to assign roles/projects appropriately (e.g. department, region, etc).
2 Likes