User authentication
SAML
Kpow can integrate with your SAML IdP of choice.
We have integration guides for common providers:
Generic configuration
AUTH_PROVIDER_TYPE=samlSAML_RELYING_PARTY_IDENTIFIER=the Audience URI (SP Entity ID), e.g. Kpow-UAT-1 or however you have named the Kpow instance in your IdP.SAML_ACS_URL=the Single sign-on URL, e.g.https://kpow.corp.com/samlSAML_METADATA_FILE=the path to the IDP metadata file, e.g./var/saml/saml-idp-metadata.xmlSAML_CERT=the path to the SAML certificate. Note: This is optional, as it is most commonly bundled inside the IDP metdata XML/var/saml/saml-cert.pemSAML_SESSION_S=3600the duration in seconds before re-authenticating SAML credentials (default 1hr)
SAML and Path-Proxied Kpow
Set AUTH_LANDING_URI when running Kpow at a proxied path.
Often our users configure Kpow behind a reverse proxy at a specific path, e.g.
https://tools.your-corp/kafka/kpow
When Kpow is proxied to a specific host/path we need to set the AUTH_LANDING_URI to that same path so the post-login redirect process can work properly, e.g.
AUTH_LANDING_URI=https://tools.your-corp/kafka/kpow
Custom role field configuration
Kpow offers Role Based Access Control for user authorization.
Roles are defined in a Roles attribute in the SAMLResponse from your IdP.
If you would like to use a field other than the Roles attribute, add the following to your RBAC configuration file.
saml:
role_field: "Groups"
Now, Kpow will look to the Groups attribute for its basis of roles.
Debugging SAML
Start Kpow with the environment variable DEBUG_AUTH=true to debug SAML configurations.
This will log the SAMLResponse payload from your IdP. You can use a tool like samltool.com to inspect and verify your IdP is correctly forwarding your configured claims/attributes.
Kpow provides an endpoint for inspecting the state of the currently authenticated user. kpow_host/me returns a JSON payload like:
{"provider": "saml",
"email": "user@corp.com",
"name": "User",
"roles": ["admin"]}