-
Notifications
You must be signed in to change notification settings - Fork 2
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
LDAP / SAML authentication for access to Elasticsearch and database #80
Comments
Please also consult Hans (and Chris) about this issue: he advised against using LDAP when I mentioned it to him. Maybe he has a better idea? |
Also think about securing corpus details. Currently the api sends all the corpora to the user and then on the client the permissions are checked. |
Goal is to have a common login for users that have a solis-id for corpora like the Times and the Guardian. And to be able to hand some users extra privileges for access to other corpora like Dutch Banking Data. Extra privileges might have to be arranged through FLASK admin but also while using solis-id. |
As it appears there is a way to avoid implementing a complete SAML protocol in the code, by making use of the service of ITS called 'access manager'. This in fact the preferred policy by ITS. The user who wants to authenticate with a solis-id, is led to a standard login screen provided by ITS. After signing in the user is forwarded to the application. In the header of the forwarding http request is the username included. This username can be used for further authorisation and access to corpora. This access manager can be used alongside the existing login procedure. Only required is an extra forwarding url (eg. Ianalyzer/loginsaml), where the header variables from access manager are handled. The access manager is a proxy that is called 'netscaler'. Is translates the SAML responses to http headers |
Does this imply that there will be two login screens? The one that already exists and a new one that works via ITS? Or do I misunderstand the meaning of 'extra' here? |
@robertloeberdevelopment Yesterday when you left, you told me you sent an email to the developer at ITS. Could you give us a quick update on what happened since our discussion yesterday? |
Tom de Haas did respond. I have send you a cc of my answer, and his answer included. Did you receive it? |
I did, thanks! |
After some more research, I found out that SAML is definitely not the way for Elasticsearch authentication. This is best illustrated by the following quote from this documentation page:
As a result, this issue splits into two independent issues: (1) Solis ID authentication for the backend, probably still using SAML, and (2) any kind of authentication (but not SAML) for Elasticsearch, in such a way that it is transparent for the user and that it requires no additional manual work on our part. I will create separate tickets for both and link back to this one from there. Automatic reverse links will appear below this post. |
For the Flask part, it seems that python-ldap is a better way to go than the (poorly documented) flask-ldap.
Here a description on Flask and LDAP
Elasticsearch provides the Security plugin which should handle LDAP authentication.
Robert:
As I now understand there was some confusion about the reason that SAML must be implemented. In fact there are two major reasons:
Login in backend for UU users with their Solis ID. Create in backend some universal permission for corpora that are to the disposal of UU users that signed in with solis ID. This feature is requested by the client.
in the api calls to elastic search there is SAML authentication needed to prevent that indexes could be deleted by a simple GET http request. Perhaps there are other ways to configure in Elasticsearch in order to prevent unwanted actions via the url?
The text was updated successfully, but these errors were encountered: