SSO compatibility

[eikek]

SSO compatibility

[eikek]

Hi @Arno500 , thank you for your suggestion! I didn't implement something like this, because there is not the standard SSO way. In my experience there are often small special cases. I'm not sure, if I understand your use-case. Is there still a username/password pair provided by the user? If so, one could use the external auth mechanism and write a shell script that does the authentication. There has been an example somewhere where it was used to authenticate against an LDAP directory. Would that maybe work for you?

Otherwise, if I knew better what is needed, I'm happy to implement it.

[Arno500]

I've not been very precise, sorry ;)

I need OpenID Connect or SAML 2.0 if you prefer (but it seems harder to implement)... Otherwise, we use an ActiveDirectory service (LDAP-compatible), but this web app may not be hosted on the same machine for security reasons and we need to develop a small and accessible webapp to do the auth, thus reducing the security. We can use the script solution, but it's not really clean, and as the LDAP server is not on the same server (both are isolated for maximum security as Sharry concerns clients and collaborators, and AD concerns exclusively collaborators)... Also, a SSO service (Trustelem) supporting these two standards is currently being deployed in the company.

[eikek]

If there is a webapp to be developed, it could also just do the auth given the username/password pair. This is already supported via external.http auth. But I guess, this also wouldn't work for you….

I'm interested in adding support for OpenID Connect, but I'm not familiar with it :/. I quickly had a look at the OpenID Connect Spec and it is quite big :) (at least compared to the old openid spec, which was really small and simple) I probably need to delegate this to some library I have to find. Or do you think there is a ~80% case I could start with that is simple to implement (you mentioned some token exchange that didn't sound so hard at first sight)?

[Arno500]

Yes the webapp is a simple solution, but not the best that could be implemented from a security standpoint, easyness and user friendliness...

OpenID is the new de facto standards for auth, and SAML2 is getting old, so OID should be the most compatible (Facebook, Google, GitHub, etc... are all supporting it)...
For OpenID, it looks quite complicated, but you need only one face of it: the "Authorization code" flow. This is what I told you earlier, with the token exchange.
I found one library for it: https://github.com/chaabaj/openid-scala, the only problem being that providers are hardcoded inside the library, for user facility. The best would be to juste set the auth mode to OpenID in Sharry's config, and include the endpoint URL (the URL containing informations about how to redirect the user), the client ID (the login of the app against the service) and the Client secret (app's password).
Then, the app needs to be compatible with HTTPS for backend check after the user authenticated. Finally, Sharry can get some informations about the user (I think it only needs its name).

Thank you very much for your fast and useful help !

[eikek]

You're welcome! But right now you are rather helping me :-) Thank you for your explanation and I like the fact that only the "authorization code" flow is needed.

I think the problem is that sharry is not really prepared for redirects in its auth subsystem. I have to add an endpoint that handles the redirect request from the authentication provider (as far as I understand?). Then I'm thinking about whether the login page makes any sense if it is configured for openid.So it is more work than I hoped…. I really like to add this, but unfortunately I'm quite low on spare time right now. I plan to add a new chunk of work after summer. I'msorry if that is too late or anything….

[Arno500]

OpenID can't login from provided infos like username and pass in the URL. You needs to authenticate on THE service containing or connecting user databases. Therefore, a login page before OpenID doesn't makes sense and would not work.
In the algorithm form, it's a bit like :
IF OpenID is set as auth provider, THEN bypass the login page and redirect to the auth provider.
After the user connects, it gets redirected to a URL endpoint you provided.
Only now, check the token given in the URL (based on your already existing Web Auth) against the server. Finally, if it corresponds, the server should send you the requested data (here only the user name is needed, maybe using the email adress if it doesn't exists)

Here it is !

You can work on it whenever you have time (and wants to take it) !

[eikek]

I know, it's been a while :-); I think this is now realized in current release.