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'
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?
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.
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.
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.
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.
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.
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"
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.