Authentication via SAML IDP possible? about konnect HOT 18 CLOSED

Hi @spaceone,

unfortunately so far it's not possible to sign in via saml. there only is experimental support for signing in via an external openid provider.

from konnect.

The only thing I found was the the experimental external-cookie-authentication plugin. Is this the way one would authenticate against a SAML IDP?

I doubt that that the cookie backend can be used with SAML.

A dedicated SAML 2.0 backend should be possible by implementing AuthNRequest with HTTP-Redirect and HTTP-Post bindings, similar to the experimental external openid provided as mentioned by @fbartels .

from konnect.

I tried to set up the cokie backend as I didn't fully understand what it is used for and what it exactly does and couldn't get it working till now. I thought it does some internal http requests which accept the authentication if the request is successfull (i.e. cookies are valid and accepted).
If that is true (which I now doubt), I could write some endpoint which can validate the SAML cookies.

Is there a plugin mechanism, where I could integrate my python saml service provider implementation which makes a saml to openid-connect mapping?

How would I set up the external openid provider authentication?

from konnect.

I tried to set up the cokie backend as I didn't fully understand what it is used for and what it exactly does and couldn't get it working till now. I thought it does some internal http requests which accept the authentication if the request is successfull (i.e. cookies are valid and accepted).
If that is true (which I now doubt), I could write some endpoint which can validate the SAML cookies.

Yes thats the point of it - if it can work depends entirely on the cookie and the general setup. Something like that

SIGNINFORM=https://mose4:8443/provider/simple/sign-in
USERINFO=https://mose4:8443/cookieserver/simple-userinfo
COOKIENAMES=minioidc-simple

konnectd serve --listen 0.0.0.0:8777 \
  --iss=https://mose4:8443 \
  --insecure \
  --sign-in-uri=$SIGNINFORM \
  --authorization-endpoint-uri=/provider/simple/konnect/v1/authorize \
  --identifier-client-path=./identifier/build \
  --identifier-registration-conf=./identifier-registration.yaml \
  --signing-private-key=examples/key.pem \
  --encryption-secret=examples/encryption.key \
  --validation-keys-path=examples/keys \
  $@ \
  cookie $USERINFO $COOKIENAMES

has been working in the past. The whole idea is that the "authorization endpoint" gets cookies it cann pass through to the backend user info endpoint. But please keep in mind that this mode of operation is limited related to what information can be fetched when (since backend access depends on a cookie value) and cannot be recommended for most use cases.

Is there a plugin mechanism, where I could integrate my python saml service provider implementation which makes a saml to openid-connect mapping?

No - also not exactly sure what you mean by that. Generally backends are "pluggable" by implementing them in Go and building the binary with it. There is no backend which can use Python as of now.

https://forum.kopano.io/topic/2728/can-we-use-external-oidc-provider/12

How would I set up the external openid provider authentication?

Since this is experimental functionality and the implementation is not finished. You might try to set it up by looking at
https://forum.kopano.io/topic/2728/can-we-use-external-oidc-provider/12 where i tried to explain how to set it up. Further feedback / tests on this are greatly appreciated so we can complete the feature with some real use cases in mind.

from konnect.

@longsleep Thanks, these information were very useful.

I think I can make it work with the cookie backend as my SAML-IDP and OpenIDC-Provider are running on the same host and the SAML cookie gives me all available user information.

But I have the following last questions:

• I implemented $USERINFO similar to the example in https://github.com/Kopano-dev/konnect/blob/master/examples/coookieserver.py.
  I am returning Content-Type: application/json with the payload {"sub":"whatever","id":1,"name":"Florian","email":"[email protected]"}.
  The konnect backend makes the request but then writes the error message into the logs:
  consent is required for offline access but not given, removed offline_access scope
  Do I have to provide more information? Is something missing?

• It is okay to have the userinfo backend only be reachable by the internal openid connect request, so I can set the url to e.g. http://127.0.0.1/user-info/, right?

• What is sign-in-uri with the cookie backend supposed to do? I see that it is accessed with a query string like:
  oauth=1 and continue=https://ucs-sso.school.dev/konnect/v1/authorize?response_type=code&scope=openid+profile+email+offline_access&client_id=wordpress-ucs&state=dd632e05c5b89a487acf8db839affee7&redirect_uri=https%3A%2F%2F10.200.27.89%2Fwordpress%2Fwp-admin%2Fadmin-ajax.php%3Faction%3Dopenid-connect-authorize
  I assume I have to redirect to the continue parameter after I successfully logged-in the user?
  When I do this, that URL redirects me immediately back to the same site and ends in a redirection loop. The backend doesn't request the $USERINFO service then.

• From security perspective I have to validate if the continue url really is the openid-connect backend url before I do the redirection. Otherwise anyone can send a malicious link to clients.

from konnect.

Wellm

• The konnect backend makes the request but then writes the error message into the logs:
  consent is required for offline access but not given, removed offline_access scope
  Do I have to provide more information? Is something missing?

This is not an error (just debug log). It means the oauth request your client sent requested offline_access but at the same time did not explicitly request the consent prompt and thus offline_access scope is automatically ignored.

• It is okay to have the userinfo backend only be reachable by the internal openid connect request, so I can set the url to e.g. http://127.0.0.1/user-info/, right?

Yes.

• What is sign-in-uri with the cookie backend supposed to do? I see that it is accessed with a query string like:

This is where Konnect will redirect if the backend request failed (assuming sign-in is required).

• I assume I have to redirect to the continue parameter after I successfully logged-in the user?
  When I do this, that URL redirects me immediately back to the same site and ends in a redirection loop

Yes, redirect to the continue parameter value (which points to the authorize endpoint). When redirecting, that request will need to include authentication cookies (as set by your sign-in provider). If no request ot $USERINFO is made, then this can only mean that no (matching) cookies are sent (nothing is logged in this case).

• From security perspective I have to validate if the continue url really is the openid-connect backend url before I do the redirection. Otherwise anyone can send a malicious link to clients.

Yes - usually a whitelist approach is used for any kind of ?continue= support. Since you have configured the endpoint to authorize you can use that in the whitelist too.

from konnect.

I made progress: I implemented the SAML->openid-connect-json backend. Now I get these messages for the $USERINFO request:
time="2019-10-13T12:37:19Z" level=error msg="identity manager fetch failed" error="CookieIdentityManager: unknown identity claims type" time="2019-10-13T12:37:19Z" level=debug msg="userinfo request user not found" sub=6gLM3iMT3dKEna32nDBvYdfLwgfW4Ps37sS_qMybQkFAebJWVd4VACjqO7owUJ70DO_KoQIUz5r1y7n2CO2V9w@konnect

• What is sign-in-uri with the cookie backend supposed to do? I see that it is accessed with a query string like:

This is where Konnect will redirect if the backend request failed (assuming sign-in is required).

• I assume I have to redirect to the continue parameter after I successfully logged-in the user?
  When I do this, that URL redirects me immediately back to the same site and ends in a redirection loop

Yes, redirect to the continue parameter value (which points to the authorize endpoint). When redirecting, that request will need to include authentication cookies (as set by your sign-in provider). If no request ot $USERINFO is made, then this can only mean that no (matching) cookies are sent (nothing is logged in this case).

My browser sends all SAML cookies along with every request. But there is one cookie from konnect:
__Secure-KKBS=UeR9dFEJ-1pU4LWA4W3VZUnHgekah5QObCP6QoT9N8g; Path=/konnect/v1/session/; Secure

This is set in the request which redirects me back to my login-uri. (Note that the path is very restrictive).

from konnect.

error="CookieIdentityManager: unknown identity claims type"

Ok this is an actual error - for some reason it fails to parse the claims. This must succeed for this to work. Can you check the access token. Unfortunately the CookieIdentityManager does not log what "type" it found to be "unknown".

But there is one cookie from konnect:
__Secure-KKBS=UeR9dFEJ-1pU4LWA4W3VZUnHgekah5QObCP6QoT9N8g; Path=/konnect/v1/session/; Secure

Yes - this is the browser state cookie and it is limited to the session endpoint (used by OIDC session management extension).

from konnect.

This must succeed for this to work.

Looking at this it seems like that functionality is currently broken :/

from konnect.

@spaceone i made a patch which might fix this

--- a/identity/managers/cookie.go
+++ b/identity/managers/cookie.go
@@ -383,14 +383,21 @@ func (im *CookieIdentityManager) Fetch(ctx context.Context, userID string, sessi
 
        if user == nil {
                // Try claims from context.
-               identityClaims, _ := konnect.FromClaimsContext(ctx)
-               if identityClaims != nil {
-                       var err error
-                       var encodedCookies string
-                       identityClaimsMap, ok := identityClaims.(jwt.MapClaims)
-                       if !ok {
+               claims, _ := konnect.FromClaimsContext(ctx)
+               if claims != nil {
+                       var identityClaimsMap jwt.MapClaims
+                       switch c := claims.(type) {
+                       case *konnect.AccessTokenClaims:
+                               identityClaimsMap = c.IdentityClaims
+                       case *konnect.RefreshTokenClaims:
+                               identityClaimsMap = c.IdentityClaims
+                       case jwt.MapClaims:
+                               identityClaimsMap = c
+                       default:
                                return nil, false, fmt.Errorf("CookieIdentityManager: unknown identity claims type")
                        }
+                       var err error
+                       var encodedCookies string
                        encryptedCookies, _ := identityClaimsMap["cookie.v"].(string)
                        if encryptedCookies != "" {
                                encodedCookies, err = im.encryptionManager.DecryptHexToString(encryptedCookies)

Please give it a try and let me know.

from konnect.

@longsleep
The error message is gone, instead the wordpress login shows me another message:
ERROR: User claim incomplete

konnectd shows:

DEBU[0004] failed to decode client session               error="decryption failed"
DEBU[0004] consent is required for offline access but not given, removed offline_access scope
DEBU[0005] identifier client lookup                      client_id=wordpress-ucs known=true redirect_uri="https://master89.school.dev/wordpress/wp-admin/admin-ajax.php?action=openid-connect-authorize" trusted=true

(the first message only once during startup(?))

Apache's access log:

ucs-sso.school.dev:443 10.205.2.7 - - [14/Oct/2019:07:13:31 +0200] "GET /konnect/v1/authorize?response_type=code&scope=openid+profile+email+offline_access&client_id=wordpress-ucs&state=538b10fe0843b98f6bd6ae1c0b75a09d&redirect_uri=https%3A%2F%2Fmaster89.school.dev%2Fwordpress%2Fwp-admin%2Fadmin-ajax.php%3Faction%3Dopenid-connect-authorize HTTP/1.1" 302 926 "https://master89.school.dev/" "Mozilla/5.0"

ucs-sso.school.dev:443 10.200.27.89 - - [14/Oct/2019:07:13:31 +0200] "POST /simplesamlphp/userinfo.php HTTP/1.1" 200 520 "-" "Mozilla/5.0" 

ucs-sso.school.dev:443 172.17.0.2 - - [14/Oct/2019:07:13:31 +0200] "POST /konnect/v1/token HTTP/1.1" 200 6038 "https://ucs-sso.school.dev/konnect/v1/token" "WordPress/5.2.4; http://master89.school.dev/wordpress" 

10.205.2.7 - - [14/Oct/2019:07:13:31 +0200] "GET /wordpress/wp-admin/admin-ajax.php?action=openid-connect-authorize&code=enwpMn2VJXjl94KKnEjeHy31BOx_NpHm&scope=openid%20profile%20email&session_state=4e37e922e5c5a6f8615f317fc20230582a56a224e32d02768a8929b994ef3865.tOBuu_bq-EGOBf0_jh7JjgPNQVOkYfICRL4LvjLomnU%3D&state=538b10fe0843b98f6bd6ae1c0b75a09d HTTP/1.1" 302 823 "https://master89.school.dev/" "Mozilla/5.0" 

ucs-sso.school.dev:443 10.200.27.89 - - [14/Oct/2019:07:13:31 +0200] "POST /simplesamlphp/userinfo.php HTTP/1.1" 200 367 "-" "Mozilla/5.0"

ucs-sso.school.dev:443 172.17.0.2 - - [14/Oct/2019:07:13:31 +0200] "POST /konnect/v1/userinfo HTTP/1.1" 200 3841 "https://ucs-sso.school.dev/konnect/v1/userinfo" "WordPress/5.2.4; http://master89.school.dev/wordpress"

10.205.2.7 - - [14/Oct/2019:07:13:32 +0200] "GET /wordpress/wp-login.php?login-error=incomplete-user-claim&message=User+claim+incomplete HTTP/1.1" 200 2206 "https://master89.school.dev/" "Mozilla/5.0"

from konnect.

The error message is gone, instead the wordpress login shows me another message:
ERROR: User claim incomplete

Well that looks good - what claims exactly Wordpress needs i do not know. Since Wordpress requests offline_access without consent (which imho is invalid), it might just complain about the lack of the refresh token.

DEBU[0004] failed to decode client session error="decryption failed"

This most likely means you have not generated persistent keys (--encryption-secret) and Konnect creates a new random one on startup.

from konnect.

DEBU[0004] failed to decode client session error="decryption failed"

This most likely means you have not generated persistent keys (--encryption-secret) and Konnect creates a new random one on startup.

I now see this happens on every request in the redirection loop, when the user is not logged in:
https://ucs-sso.school.dev/konnect/v1/authorize?response_type=code&scope=openid+profile+email+offline_access&client_id=wordpress-ucs&state=abf3de0eeb58aba91e8fa06be59c2caa&redirect_uri=https%3A%2F%2Fmaster89.school.dev%2Fwordpress%2Fwp-admin%2Fadmin-ajax.php%3Faction%3Dopenid-connect-authorize
The code says this is harmless if no session exists:
https://github.com/Kopano-dev/konnect/blob/master/oidc/provider/handlers.go#L161

Nevertheless, I am ending in the redirection loop if the $USERINFO endpoint just returns 401. Could you give me a patch which adds debug logging messages for the steps which occur during the cookie authentication?

Regarding the wordpress problem, I think I will try to use another OIDC app to test the login (e.g. nextcloud or kopano).

from konnect.

Ahh! Sorry, forget the redirection loop. I think I got it now.

from konnect.

It works with nextcloud (well after a internal server error first but after a refresh one is logged in)!
Thank you very much.

Will you merge your patch? Or should I create a PR?

from konnect.

Will you merge your patch? Or should I create a PR?

i will, internal PR already made

from konnect.

Thanks for testing and reporting back 👍

from konnect.

I posted this on the Kopano forum but perhaps this is best to sit here.

I'm taking a look at Konnect to get a better handle on how Single Sign on works. I'm able to get it to work against the KC backend, but noted inside the sample identifier.yaml that there is SAML2 support.

Am I correct in thinking that I could have Konnect whenever it is called authenticate against my SAML2 IDP Provider (with it exporting a uid value) allowing my central authentication system to have to take the place of logging in yet again to use Konnect services?

I did try to enable the SAML2 component in the identifier configuration and Konnect states that it has been loaded.

INFO[0000] authority is now ready id=llng type=saml2 and forwards to my own IDP, yet throws errors because it has not been setup on the IDP as a Service Provider.

I'm not super up to speed on authentication but with setting up other SAML2 entities I have required metadata on both the IDP and SP end. I've tried to look in the Konnect code to see if there is a path that I can use for getting this metadata with no such luck.

The closest I can find is curl 127.0.0.1:8777/konnect/v1/identifier/saml2/metadata however I get a 404 response.

Any advice? I'll report my findings and write up a tutorial for others to benefit from if I can get this going.

I am starting it on the command line as such for now:

/usr/libexec/kopano/konnectd serve --identifier-client-path=/usr/share/kopano-konnect/identifier-webapp --identifier-registration-conf=/etc/kopano/identifier-registration.yaml.in --iss=https://konnect.example.com dummy

^^ Note I have also tried kc as the backend

My identifier config looks as such:

---

  - id: llng
    name: llng
    entity_id: kopano-konnect
    authority_type: saml2
    default: yes
    trusted: yes
    discover: yes
    metadata_endpoint: https://auth.example.com/saml/metadata
    identity_claim_name: uid
    identity_alias_required: false
    end_session_enabled: true

Regards.

from konnect.