ReadOnlyRest keycloak integration

1

Hello!
As @sscarduzio suggested, I started a new topic about keycloak and ReadOnlyRest integration because I need help.

The current manual (https://github.com/beshu-tech/readonlyrest-docs/blob/master/keycloak_saml.md) just says “import this config and don’t care” which doesn’t work for us, because we have standalone keycloack which we want to use and don’t want to import anything to master realm.

So, it would be great to have a step-by-step manual.

Currently, I`m stuck with “[org.keycloak.events] (default task-85) type=LOGIN_ERROR, realmId=LDAP_test, clientId=null, userId=null, ipAddress=10.190.44.179, error=invalid_signature” error.

What Canonicalization method should I use?
What Signature algorithm should I use?
Should /ror_kbn_sso_saml_serv1/assert/ be accessible for anyone? It shows me “{“statusCode”:400,“error”:“Bad Request”,“message”:“Invalid cookie value”}”.

2

Have you tried to stand up a Keycloak and import the config file, then go back to the settings UI and see what’s there?

3

No, because i don’t want to make any changes into master realm.

4

yeah but why don’t you download a disposable standalone keycloak just for testing and copy over the settings that you notice you were missing? That’s what I mean!

5

Ok, looks like the problem was with “sign document” turned on.
Looks like auth started to work, we have proper redirects to keycloak and back, but after that we have “{“statusCode”:401,“error”:“Unauthorized”,“message”:“Invalid signature”,“attributes”:{“error”:“Invalid signature”}}”

Looks like some extra tweaks should be done on readonlyrest side, but i can’t find any info about it.

By the way, i imported provided json intro disposable keycloak and it became broken, becase json changes admins group for whatever reason if you choose not to skip import of setting which allready exist :smiley:

UPD: switched off “sign document” and removed saml certs from readonlyrest config file and looks like auth starts to work! Now i have “unable to login” error in ror gui

6

That could be from ACL settings. What’s in the ES Logs?

7

Looks like we have to change the docs to skip the json and manually configure everything so it’s more adaptable, more explicative and less error prone.

We definitely have some work to do in terms of documentation.

8

We definitely have some work to do in terms of documentation.
It could be great, thanks!

That could be from ACL settings. What’s in the ES Logs?
Not sure there is any ACL setting at the moment. My colleague is doing the ES side, not me.

So, after we set up keycloak integration what should we do on ROR/ES side?

Could ACL be set up for a custom token claim?
We would like to check if the user is a member of AD group (group membership are passed into token)

9

Yes of course! You can identify a claim inside the SAML assertion to be the list of groups using the “groupsParameter” key in your kibana.yml when you configure the SAML connector.

For example:

eadonlyrest_kbn:

  logLevel: debug
  clearSessionOnEvents: ["login"]

  auth:
    signature_key: "my_shared_secret_kibana1_(min 256 chars)" # <- use environmental variables for better security!

    saml_azure:
      buttonName: 'Azure AD SAML SSO'
      enabled: true
      type: saml
      issuer: 'ror'
      protocol: 'https'
      cert: '/etc/kibana/config/cert.pem' # <-- will download later from Azure enterprise app dashboard
      entryPoint: 'https://login.microsoftonline.com/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/saml2'
      kibanaExternalHost: 'localhost:5601'
      usernameParameter: 'http://schemas.microsoft.com/identity/claims/displayname'
      groupsParameter: 'http://schemas.microsoft.com/ws/2008/06/identity/claims/groups'

The above is taken from our AzureAD + SAML tutorial