External auth provider

[gelim]

Hello,

I would like to assess the difficulty to have external provider authenticating the pwndoc users and passing along the identity via the HTTP header REMOTE_USER. How do you see that feasable?

User creation could be done at pwndoc level (prerequisite to have a successfull access) but auth would be trusted from the HTTP header.

What are your thoughts on that? Cheers

[yeln4ts]

Hi,

Since the user creation is done inside the application I don't know if it would be relevant to add external auth providers in the authentication process. It would be interesting if you could sign up as it would facilitate the process but in the present case that is not the goal.

[gelim]

I think it is very relevant for people working with an external auth provider and not willing to disseminate authentication base on each apps deployed. What I'm thinking of is a light way to do SSO without taking over the user creation part. Workflow for a new user + connection would be like:

1. Create new user in pwndoc in form of it's sAMAccountName (if that's what the SSO provider will pass you in the REMOTE_USER HTTP header), You can imagine having a global check box for SSO that will grey out the password field
2. Have a reverse-proxy using pwndoc as the backend, and when the external provider is enabled, REMOTE_USER will be transmitted via HTTP header. I did implement that successfully already with apache2 + libapache2-mod-auth-mellon (for SAML2 compatible SSO providers) and can contribute here sample proxy conf
3. Have pwndoc handle the REMOTE_USER and fallback to legacy auth if not defined

Hope that draws betters what I'm proposing. I began to look at the code base, but for me the time barrier is being confortable with the whole paradigm behind JS/Node stuff

[WhiteWinterWolf]

How such feature is commonly done:

• The reverse-proxy and the application (here Pwndoc) should share a common secret, the reverse-proxy passes the REMOTE_USER header you mentioned plus another header containing a HMAC of the username using the shared secret. This is to prevent an attacker able to bypass the reverse-proxy to freely forge arbitrary REMOTE_USER headers.
• As Pwndoc is designed around a local users database, you may want to create the local user on-the-fly upon his first successful connection. There should be a way to retrieve the groups the user belongs to (usually through LDAP, but this information can also be provided by the reverse-proxy if you also ensure its authenticity), then a mapping can be configured to associate certain groups from the external repository to Pwndoc roles so the newly created user can be associated to the right roles.

You may want to check #106 which may already provide on-the-fly users creation mechanism as part of LDAP-integration and build on this to achieve SSO reverse-proxy authentication.