User authentication

SAML

Kpow can integrate with your SAML IdP of choice.

We have integration guides for common providers:

Generic configuration

  • AUTH_PROVIDER_TYPE=saml
  • SAML_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/saml
    
  • SAML_METADATA_FILE= the path to the IDP metadata file, e.g.
    /var/saml/saml-idp-metadata.xml
    
  • SAML_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.pem
    

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": "[email protected]",
 "name": "User",
 "roles": ["admin"]}
Previous
Okta