Issue with SAML authentication w/ enterprise edition


(Dustin Scott) #1

I’m trying to get the newly available SAML authentication working with the enterprise edition. Based on the documentation available, I believe I have the correct settings, however, when I try to authenticate using our IDP, I get a 404 error. I get the same result regardless of if I attempt the authentication directly from our IDP or through the SAML SSO link within Kibana.

kibana.yml:

readonlyrest_kbn.auth:
  signature_key: "my_shared_secret_kibana1"
  saml:
    enabled: true
    entryPoint: 'https://company.okta.com/app/company_testsecops_1/exk1gfw3icm0It5o00h8/sso/saml'
    kibanaExternalHost: 'secops.vlab.local:5601' # <-- public URL used by the Identity Provider to call back Kibana with the "assertion" message
    issuer: 'http://www.okta.com/exk1gfw3icm0It5o00h8'
    usernameParameter: 'user.email'

The SSO URL I am using at my IDP is “http://secops.vlab.local:5601/ror_kbn_sso/metadata.xml


(Simone Scarduzio) #2

Hi @dscott98, I think the issue is that the URL you set up there is not reachable by okta over the internet (i.e. it’s not a public URL)


(Dustin Scott) #3

that shouldn’t be an issue, as we’re using okta to authenticate other internal applications. Is there an option to turn up the log level to see what resource is being requested that is not found?


(Simone Scarduzio) #4

Hi @dscott98,

I tried to integrate with Okta, it worked well for me with this configuration:

readonlyrest_kbn.auth:
  signature_key: "sharedsecret123456"
  saml:
    enabled: true
    entryPoint: 'https://readonlyrest.okta.com/app/readonlyrest_rorsaml_1/exk1wpyws0irjLsUj356/sso/saml'     
    logoutUrl:  'https://readonlyrest.okta.com/app/readonlyrest_rorsaml_1/exk1wpyws0irjLsUj356/slo/saml'     
    kibanaExternalHost: 'rorsaml.localtunnel.me'
    usernameParameter: 'nameID'
    groupsParameter: 'memberOf'

And my settings in Okta:


(Dustin Scott) #5

Thanks for the update. I think we’re making progress, but I’m now getting a different error. I’ve taken your settings, and adapted them to my environment.


(Simone Scarduzio) #6

Hi @dscott98!
That is a compatibility problem between JJWT and Java 9 or greater. This is resolved in the latest commit I just created. As a workaround for now, just run ES with Java 8.


(Dustin Scott) #7

Thanks Simone. If I were to grab the latest plugin, would the issue be resolved, or has the patch not yet been applied to the public?

Thanks, again.


(Dustin Scott) #8

Also @sscarduzio. I am able to get this working in our production systems. We are looking at upgrading from 6.3 to 6.4.1, during which, we will also be looking at upgrading Java to v9. I’m happy to help test the fixes you have implemented for Java 9.

How would we go about implementing different levels of access with SAML authentication? Ideally we’d like to use group membership or some other attribute within our SSO provider (Okta) to facilitate this. I’m just not sure where we reference this information in the access control rule section of the ROR plugin.

Thanks again for all the help.


(Simone Scarduzio) #9

Here is the build with today’s fixes. Not sure which version you needed. Please try it out.

readonlyrest-1.16.28-pre1_es6.4.1.zip

readonlyrest-1.16.28-pre1_es6.3.2.zip

readonlyrest-1.16.28-pre1_es6.3.0.zip


(Simone Scarduzio) #10

In the SAML connector configuration in Kibana you can set the name of a field in the SAML assertion JSON that will be interpreted as the list of groups the user belongs to.

kibana.yml

readonlyrest_kbn.auth.saml.groupsParameter: 'memberOf'

This information can be used to create ACL blocks on the ES side like so:

readonlyrest.yml

readonlyrest:

  access_control_rules:
  
    - name: "::KIBANA SERVER::"
      auth_key: kibana:kibana
      verbosity: error

    - name: SAML viewer users
      kibana_access: ro
      ror_kbn_auth:
        name: kbn1
        roles: ["viewer"]

    - name: SAML admin users
      kibana_access: admin
      ror_kbn_auth:
        name: kbn1
        roles: ["admin"]

    - name: Other SAML users
      kibana_access: ro
      ror_kbn_auth:
        name: "kbn1"

  ror_kbn:
    - name: kbn1
      roles: ["ror_kibana_users"] # never allow any SAML users that don't have at least this role
      signature_key: "1234.....567890" #loooong key

(Dustin Scott) #11

Again, appreciate all the help on this. where are the “roles” defined? Are these the values of the “memberOf” attribute? or defined elsewhere?

If all of these questions are in a document somewhere, please feel free to point me in that direction.

Thanks again.


(Simone Scarduzio) #12

Hi @dscott98, in the example the “membeOf” field of the assertion should contain an array of strings (the roles/groups).

The whole meaning of this procedure is to be able to delegate authorization to SAML.

In fact, the aforementioned assertion message is a XML document (immediately transformed to JSON by ROR once received) that comes from the identity provider (your SAML authentication server) towards the service provider (your Kibana).

The feature is new, and its documentation is process, the feature is new. Will soon be much better.


(Dustin Scott) #13

I guess the part that I’m missing is how do I correlate the group the person is in, which is passed by the ‘memberOf’ field of the SAML assertion to the ACL as defined below:

Assuming this is done somehow through a mapping of ‘memberOf’ to a role, but I’m not sure where the roles are defined.

 access_control_rules:

    - name: "Okta admin users"
      kibana_access: admin
      actions: ["*"]
      ror_kbn_auth:
        name: "kbn1"
        roles: ["admin"]

    - name: Okta viewer users
      kibana_access: ro
      ror_kbn_auth:
        name: kbn1
        roles: ["viewer"]

  ror_kbn:
    - name: kbn1
      roles: ["ror_kibana_users"] # never allow any SAML users that don't have at least this role
      signature_key: "somethingsuperlonghere"

(Simone Scarduzio) #14

Well the whole point of a authentication and authorization connector is to administer these concerns in a remote system. So in this case, delegating authorization to SAML means that we enter the SAML IdP administration console, and associate roles (strings) to users. This information is going to trickle down into ROR, where it will be associated to an ACL block where rules define what a valid user that belongs to that role can do.