Question: is it possible to authenticate clients against multiple clients data sources (first successful finish checking)? #82

New issue

Closed

opened 2020-01-03 14:23:31 +01:00 by rurus9 · 6 comments

rurus9 commented

2020-01-03 14:23:31 +01:00

(Migrated from github.com)

Something like:
I have configured three clients backends: two LDAP and one database client backend.
Client try to get JWT token (in client_credential flow):

Glewlwyd try to authenticate client against first backend - negative, don't give up... ->
Glewlwyd try to authenticate client against second backend - positive, client authenticated, glewlwyd can issue a JWT token.
Is it possible with glewlwyd?

Something like: I have configured three clients backends: two LDAP and one database client backend. Client try to get JWT token (in client_credential flow): 1) Glewlwyd try to authenticate client against first backend - negative, don't give up... -> 2) Glewlwyd try to authenticate client against second backend - positive, client authenticated, glewlwyd can issue a JWT token. Is it possible with glewlwyd?

babelouest commented

2020-01-03 16:17:25 +01:00

(Migrated from github.com)

Hello,

You can have multiple backends for users and clients. Therefore the client verification flow goes like this:

loop in all backends according to their priority
checks the client against the current backend
if the backend returns not found, checks the next client backend
if the backend returns ok or unauthorized, stops the search and returns the value
If all backends returned not found, then returns unauthorized

So there's a difference between not found and found but password or client_secret invalid.

Hello, You can have multiple backends for users and clients. Therefore the client verification flow goes like this: - loop in all backends according to their priority - checks the client against the current backend - if the backend returns `not found`, checks the next client backend - if the backend returns `ok` or `unauthorized`, stops the search and returns the value - If all backends returned `not found`, then returns `unauthorized` So there's a difference between `not found` and `found but password or client_secret invalid`.

rurus9 commented

2020-01-07 12:41:23 +01:00

(Migrated from github.com)

I assumed it works that way, but...
When "Database backend client module" is first, I can't authenticate clients against LDAP (AD) - every time in logs I have:
Glewlwyd DEBUG: oauth2 check_auth_type_client_credentials_grant - Error client_d 'CLIENT_ID' invalid

When "LDAP backend client module" is first, LDAP (AD) authentication works...

I assumed it works that way, but... When "**Database backend client module**" is first, I can't authenticate clients against LDAP (AD) - every time in logs I have: `Glewlwyd DEBUG: oauth2 check_auth_type_client_credentials_grant - Error client_d 'CLIENT_ID' invalid` When "**LDAP backend client module"** is first, LDAP (AD) authentication works...

babelouest commented

2020-01-07 18:22:42 +01:00

(Migrated from github.com)

Hello,

Can you explain what flow you are using to get this error?
Also, what is the plugin used? Oauth2 or OIDC?
Are the client and user LDAP backends in readonly?

I can't reproduce your bug but probably your configuration will help me to

Hello, Can you explain what flow you are using to get this error? Also, what is the plugin used? Oauth2 or OIDC? Are the client and user LDAP backends in readonly? I can't reproduce your bug but probably your configuration will help me to

rurus9 commented

2020-01-08 09:12:05 +01:00

(Migrated from github.com)

Start new, clean docker instance:
docker run --rm -it -p 4593:4593 babelouest/glewlwyd
or
docker run --rm -it -p 4593:4593 src:20200108 (I built this docker today).

Add proper "LDAP backend client module" (read only) - you can see clients in frontend.

So you have two client modules:
0. Database backend client module (it's empty now, but it's first. When it contains clients it's the same...).
1. LDAP backend client module.

Add oauth2 plugin (I only filled name: "oauth2", display name: "oauth2", and Tokens signature - JWT type: "RSA", Key size: "512 bits", and public and private key).

When you try to obtain token in Client credentials flow, you have "HTTP/1.1 403 Forbidden".
When you change the order (LDAP backend client module is first), you can get token.

Start new, clean docker instance: `docker run --rm -it -p 4593:4593 babelouest/glewlwyd` or `docker run --rm -it -p 4593:4593 src:20200108` (I built this docker today). Add proper "**LDAP backend client module**" (**read only**) - you can see clients in frontend. So you have two client modules: **0. Database backend client module** (it's empty now, but it's first. When it contains clients it's the same...). **1. LDAP backend client module**. Add **oauth2** plugin (I only filled name: "oauth2", display name: "oauth2", and Tokens signature - JWT type: "RSA", Key size: "512 bits", and public and private key). When you try to obtain token in Client credentials flow, you have "HTTP/1.1 403 Forbidden". When you change the order (LDAP backend client module is first), you can get token.

babelouest commented

2020-01-08 18:34:58 +01:00

(Migrated from github.com)

Hello,

Thanks to your additional information, I could pinpoint the bug, this should be fixed in github.com/babelouest/glewlwyd@4f297a993e now, can you validate the fix?

Hello, Thanks to your additional information, I could pinpoint the bug, this should be fixed in https://github.com/babelouest/glewlwyd/commit/4f297a993ee304ab5ed75192c81d44deaa56d25e now, can you validate the fix?

rurus9 commented

2020-01-09 15:39:43 +01:00

(Migrated from github.com)

Yes, with docker I built today no matter what the order is clients data sources, I can always obtain token.
Thanks.

Yes, with docker I built today no matter what the order is clients data sources, I can always obtain token. Thanks.

👍 1

This discussion has been locked. Commenting is limited to contributors.