Skip to main content
Kinetic Community

Authentication

Document Overview

The following document will assist in documenting the authentication scenario(s) used in the Kinetic Request implementation.

Authentication  Overview

Kinetic Request allows authors to specify whether a request submitter should be authenticated before being able to submit a request.    This authentication configuration is done on a form-by-form basis to allow maximum flexibility.

In addition, each form can set the following is controlled based on security definitions:

Form Display, Submission Access, Form Modification, Submission Modification. 

 

Kinetic Core Security Configuration

Summary

Kinetic Core security is driven entirely by the Spring Security structure and processing. On the surface there are two configurable items: authentication filters and authentication providers.

Authentication filters generate "tokens" that authentication providers validate. For example the X509AuthenticationFiltergenerates a PreAuthenticationToken that is handled by the PreAuthenticationProvider. Our actual implementation supports this by registering the filter through the X509FilterConfigurer and the provider through the X509SecurityProviderConfigurer. These are configured indepenently beacause their work happens at seperate stages in the process.

Configuring Authentication Support

Shared Space Security Configuration

The space security file, e.g. security.acme.properties has two confiurgable parameters. Not all providers will respect this parameters, you will have to inspect them individually.

  • security.autoupdate - if provider supported, the provider will update the local user record from then authentication source.
  • security.autocreate - if provider supported, the provider will automatically create a local user record from the authentication source.

Configuring LDAP Support

The LDAP support uses the internal username and password filter and thus only requires a provider to be configured.

Configuring Provider

Add com.kineticdata.core.web.security.configurer.LdapSecurityProviderConfigurer to the space security properties file (e.g. security.acme.properties).

Here is an example of the rest of the configurable parameters. Add these to space security properties file as well:

security.providers=com.kineticdata.core.web.security.configurer.LdapSecurityProviderConfigurer
security.ldap.context.url=ldap://domaincontroller.acme.com:389
security.ldap.context.baseDN=CN=Users,DC=acme,DC=com
security.ldap.context.bindDN=CN=Administrator,CN=Users,DC=acme,DC=com
security.ldap.context.bindPswd=adminpass1
security.ldap.user_search_base=CN=Users,DC=acme,DC=com
security.ldap.user_search_filter=(sAMAccountName={0})
# These Attributes are used to map users looked up to the user table.
security.ldap.attributes.email=userPrincipalName
security.ldap.attributes.displayName=displayName

A quick run down of what these properties are:

  • security.ldap.context.url is the URL to the LDAP server to execute queries and bind against.
  • security.ldap.context.bindDN is the DN of the account used to query for user information.
  • security.ldap.context.bindPswd is the password of the above account.
  • security.ldap.user_search_base is the base container used for searching for users.
  • security.ldap.user_search_filter is an LDAP filter used to provide criteria to match LDAP objects to usernames.

The next two configuration objects are used to automatically update Kinetic Core's internal object with details from the LDAP directory. The property value is the LDAP attribute to map.

Configuring X509/CAC Support

Prerequisites

The X509/CAC support requires some configuration outside of the Kinetic Core application. For example if you are using Tomcat you will need to configure Tomcat's SSL like this:

<Connector port="8443" protocol="org.apache.coyote.http11.Http11NioProtocol"
               maxThreads="150" SSLEnabled="true" scheme="https" secure="true"
               clientAuth="want" sslProtocol="TLS"
               keystoreFile="keystores/kineticcore.jks" keystoreType="JKS" keystorePass="keypass1"
               truststoreFile="keystores/cacerts.jks" truststoreType="JKS" truststorePass="cacerts1" />

The important part of this configuring is the clientAuth="want" parameter. This indicates to Tomcat to ask the browser for a user certificate but not reject the request if one is not provided. If it is set to "true" it will enforce the need for a certificate. If set to "false" it will never ask for a certificate but if one is provided it will still pass it through to Kinetic Core. Tomcat does not allow you to apply this requirement to URL patterns, to achieve this you will need a third party appliance or reverse proxy in front of your J2EE container.

Configuring Filter

Add com.kineticdata.core.web.security.configurer.X509FilterConfigurer to the global security.properties file. The filter only has one configurable property: security.filters.x509.matchPattern. This property takes a regular expression which is used to extract the subject information from the certificate. This affects the user search filter defined in the provider configuration.

If not specified it will extract the value of the first CN in the subject and your user search filter will have to be (cn={0}) for example.

Configuring Provider

Add com.kineticdata.core.web.security.configurer.X509SecurityProviderConfigurer to the space security properties file (e.g.security.acme.properties).

Here is an example of the rest of the configurable parameters. Add these to space security properties file as well:

security.x509.context.url=ldap://domaincontroller.acme.com:389
security.x509.context.baseDN=CN=Users,DC=acme,DC=com
security.x509.context.bindDN=CN=Administrator,CN=Users,DC=acme,DC=com
security.x509.context.bindPswd=adminpass1
security.x509.user_search_base=CN=Users,DC=acme,DC=com
security.x509.user_search_filter={0}
# These Attributes are used to map users looked up to the user table.
security.x509.attributes.username=sAMAccountName
security.x509.attributes.email=userPrincipalName
security.x509.attributes.displayName=displayName

Many of these parameters are the same as the ones used for the LDAP provider. The X509 provider functions similarly to the LDAP provider in that it uses LDAP to perform its authentication but what differentiates it is that it has its own filter which pre-authenticates the user using a certificate. The certificate typically will contain the "subject" of the certificate which is the LDAP DN of the user and not the username.

In the case of the X509 provider the user_search_base is how to find the user by DN, not username. The other additional parameter not on the LDAP provider is the security.x509.attributes.username configuration. This identities the attribute on the user object that represents the username - the system will then use the LDAP object and this username to look up (and optionally update or create) the local user record.

See the LDAP Provider configuration section for details on the shared configuration properties.

 

Sample Login Page

This page was created with Kinetic Request.  Any requests to a service item that requires authentication are redirected to this login page.  The user is then authenticated against the AR System by default. 

 loginScreen.png

 Previous (Reporting)                                                                                                 Next (Installation Prerequisite Planning)