add keycloak as external oauth handler

[rcernich]

Adds support for using Keycloak as an external authentication handler. The handler is configured by loading a json formatted file containing the Keycloak client configuration (realm, auth url, client id, client secret, etc.). This information is generated by Keycloak, which simplifies creation of the file (i.e. copy/paste).

[rcernich]

Not sure what the failure is coming from. Is the test case in question unstable, a timing issue perhaps? (it seems to have passed on the other two builds; other pr's seem to have similar problems with the test).

[liggitt]

state.Encode() handles QueryEscape-ing the values

[rcernich]

I was having an issue where the URL was not encoded and part of "then" was being processed through the main query, specifically request_type was not part of "then" but was seen as a separate parameter (e.g. state, then, request_type)

[liggitt]

From what I can see, state is getting encoded correctly on our side. This is working with both Google and Github as external OAuth providers (queries wrapped for readability):

1. Console redirects to OpenShift OAuth /authorize endpoint:

   GET https://localhost:8443/oauth/authorize?
   client_id=openshift-web-console&
   response_type=token&
   state=%2F&
   redirect_uri=https%3A%2F%2Flocalhost%3A8444%2Foauth

2. OpenShift OAuth /authorize endpoint redirects to Google:

   < Location: https://accounts.google.com/o/oauth2/auth?
   access_type=offline&
   client_id=...&
   include_granted_scopes=true&
   redirect_uri=https%3A%2F%2Flocalhost%3A8443%2Foauth2callback%2Fgoogle&
   response_type=code&
   scope=profile+email&
   state=csrf%3D...%26then%3D%252Foauth%252Fauthorize%253Fclient_id%253Dopenshift-web-console%2526response_type%253Dtoken%2526state%253D%25252F%2526redirect_uri%253Dhttps%25253A%25252F%25252Flocalhost%25253A8444%25252Foauth

3. Google does stuff

4. Google redirects back to OpenShift OAuth callback:

   < Location: https://localhost:8443/oauth2callback/google?
   state=csrf%3D...%26then%3D%252Foauth%252Fauthorize%253Fclient_id%253Dopenshift-web-console%2526response_type%253Dtoken%2526state%253D%25252F%2526redirect_uri%253Dhttps%25253A%25252F%25252Flocalhost%25253A8444%25252Foauth&
   code=...&
   scope=https://www.googleapis.com/auth/userinfo.profile+https://www.googleapis.com/auth/userinfo.email

5. OpenShift OAuth callback validates the code, parses the state, and redirects back to OpenShift /authorize:

   < Location: /oauth/authorize?
   client_id=openshift-web-console&
   response_type=token&
   state=%2F&
   redirect_uri=https%3A%2F%2Flocalhost%3A8444%2Foauth

[liggitt]

Can you make sure keycloak is not altering the state passed to it? For example, the state sent to Google in step 2 is echoed back exactly in step 4. Seems like keycloak might be doing an extra decode, not treating state as an opaque value

[rcernich]

I'll check that. I suspect you're right. In my tests, I was getting redirected to oauth/authorize?client_id=openshift-web-console (no other parameters).

[liggitt]

For maximum compatibility, it might be worth changing our DefaultState impl to base64 encode and decode, just to avoid issues with external providers accidentally decoding state. Still, checking/fixing keycloak state handling as necessary should probably happen as well...

[rcernich]

Thanks for the detailed feedback. I'll clean it up and investigate the issue with keycloak not preserving state.

[liggitt]

Does the keycloak config have a way to specify the trusted roots of the auth server? That wasn't an issue for github/google, but it likely will need to be able to be specified when hitting a self-hosted auth server. The Provider interface would need a new GetTransport() method which could return nil by default, and be overridden if trusted roots needed to be set.

[liggitt]

It also means that if the provider config will include a file reference for a trusted cert bundle, NewProviderFromConfigData would need a path to resolve file references relative to

[rcernich]

Good point. The documentation doesn't cover any of this. I suspect this is left up to the user to ensure they've configured their key/trust stores appropriately. I'll walk through their ssl example and see what shakes out. I should probably also test ssl on the OS side of things as well.

[rcernich]

I incorporated the other feedback, but was not able to get an https connection working. Looking at the code, it appears the auth transport is configured with the root certs for the OS instance. I was able to confirm that the cert used by the KC application was being picked up and included in that list and while I was able to get past some authorization errors (e.g. no SAN IPs), I was not able to get past "certificate signed by unknown authority." This was even when I used the OS CA cert to sign the cert used by KC. This is pretty far outsided my realm of expertise and it's possible I just haven't created the certificate properly (e.g. the SAN IPs issue above). Regardless, the change should be good to go, barring the fact that you can't use https for the KC auth server at this time.

[liggitt]

I think the outgoing request to the external OAuth server actually uses the system trusted roots, so I'm not surprised it's not picking up the OpenShift certs

[rcernich]

I'm not sure why the asset tests are failing, nor can I find the actual errors in the log (don't know what to look for).

[liggitt]

use base64.URLEncoding to encode/decode since we're going to use the value in a url

[liggitt]

looks good, thanks... we have a PR in progress that is moving some of the startup bits around, so I'll hold this one until that goes in.

[liggitt]

don't worry about the asset tests, those were fixed in another branch

[rcernich]

Updated the PR based on your comments (URLEncoder, no fail if handler init fails, make sure realm name is encoded properly). Regarding the cert stuff, I thought this might have taken care of things, but it doesn't (https://github.com/openshift/origin/blob/master/pkg/cmd/server/origin/auth.go#L286). Thanks again for all the feedback.

[rcernich]

rebased and push -f'd. should be ready to go.

[liggitt]

Thanks, this is on my list... should get to it soon...

[openshift-bot]

Origin Action Required: Pull request cannot be automatically merged, please rebase your branch from latest HEAD and push again

[liggitt]

@rcernich I haven't forgotten about this... we're working on externalizing OAuth config in #1426... once that's done, I'll look at pulling this in

[liggitt]

FYI, pulled in base64 encoding in #1608

Since Keycloak has OpenID Connect support, I'd like to see if we can integrate with both Keycloak and Google using a single configurable OIDC identity provider.

[liggitt]

#1631 should allow Keycloak to be supported as a generic OpenID Connect provider.

@rcernich can you see if you can sign in using your Keycloak server by doing the following:

1 - Generate a master config by running openshift start master --write-config --config=master.yaml

2 - Edit the master.yaml config file and replace the identityProviders: stanza with this:

  identityProviders:
  - name: keycloak
    challenge: false
    login: true
    provider:
      apiVersion: v1
      kind: OpenIDIdentityProvider
      ca: /path/to/keycloak-ca.crt
      clientID: YOUR_CLIENT_ID
      clientSecret: YOUR_CLIENT_SECRET
      claims:
        id:
        - sub
        preferredUsername:
        - preferred_username
        name:
        - name
        email:
        - email
      urls:
        authorize: https://YOUR_SERVER/auth/realms/YOUR_REALM/tokens/login
        token: https://YOUR_SERVER/auth/realms/YOUR_REALM/tokens/access/codes

3 - Start OpenShift with openshift start master --config=master.yaml

You should be able to log into the web console. If you can, I'd be curious to see the output of the following (run as cluster-admin):

• osc get users -o json
• osc get identities -o json

[liggitt]

documentation is at https://github.com/liggitt/openshift-docs/blob/openid/architecture/authentication.adoc#openid-connect if needed