Service Instance Authentication Modes

When you register a Service Instance you need to tell K2 what authentication mode to use. The authentication mode determines what credentials are passed to the target system at runtime, allowing you to leverage any existing security that might be defined for those systems. In other words, when a Service Instance is configured to use static credentials, K2 will always use the hard-coded username and password to connect to the back-end system. When a Service Instance is configured to use Impersonate, K2 will use the credentials of the currently-connected user when it connects to the back-end system, effectively "passing through" the credentials of the user that is viewing the Form. Understanding the available authentication modes is important because it will help significantly when troubleshooting security and authentication errors, and to configure and create appropriate security mechanisms to secure systems.

First, let’s clarify the difference between two fundamental security terms: Authentication and Authorization

Authentication is the process of verifying credentials and proving the legitimacy of the verified credentials. Often, the result of an authentication operation is a credential (“key”) that is assigned to a user. The user can then use this credential for authorization purposes.

Authorization is the process of validating a credential’s permission for a resource, and enforcing that permission. Most commonly, authorization involves checking a user’s credentials against some security rules in an application to determine whether the user is allowed to access the resource they are requesting. Think of authorization as a “lock” which requires a certain key – if the user’s credentials (“key”) opens the lock, they have access to the requested resource.

Consider the diagram shown in the slide that accompanies this topic. We have specifically indicated the K2 security features in a green-highlighted block and we will look at those first. The other areas of the diagram will help you understand how K2 SmartObject security fits into the big picture.

The two most important components in the K2 Security area are the Security Providers and the Service Instance Authentication Mode settings.

Security Providers are plug-ins that are used for authorization of user credentials. In most K2 environments, K2 leverages the existing Active Directory environment, and K2 is installed with the default Active Directory security provider as standard. The Active Directory provider allows Active Directory users to use their AD credentials to sign onto the K2 server, so there are no additional security prompts to the user. In some cases, it is necessary to authenticate external users on the K2 server. For example, an organization may allow customers and partners to utilize some of the organization's systems, but those users do not have Active Directory accounts. K2’s security provider framework can be extended with custom security providers, and developers can register these custom security providers on a K2 environment. External users can then be authenticated on the K2 server using a specific security label: the label tells K2 to use the custom security provider to authenticate the user.

The second component to understand is the Service Instance Authentication Mode options. When a service instance is registered, part of the configuration process is to tell K2 what authentication settings the service broker should use when connecting to the data provider. (See the screenshot below for an example of where this option is set.)

Selecting the Authentication Mode

There are 5 available modes: Service Account, Impersonate, SSO, Static and OAuth.

Service Account

The Service Account setting means that K2 will use the service account for the K2 blackpearl server service to connect to the provider. This approach is mostly used when it is not necessary to pass the connected user's credentials through to the provider, for example, when querying lookup information or non-secure data. This is the simplest and easiest approach to use, but at the expense of security. Of course, you should ensure that the K2 service account has permission to perform the actions that may be called by the Service Broker. This mode only works if the underlying provider supports windows authentication.

If the provider implements auditing, all audit entries will appear as the K2 service account, not the user who may have been interacting with the data on a user interface.

Impersonate

When using the Impersonate setting, the currently-connected user's credentials are passed to the provider. Although the K2 service account is executing the code in the Service Broker, K2 will "impersonate" the connected user and pass their credentials through to the provider transparently. As far as the provider is concerned, it is as if the user connected directly to it. The Impersonate setting is mostly used when you need to preserve the security and authorization settings for your provider and ensure that users cannot execute methods or see data they are not allowed to see.

This mode only works if Impersonation is set up correctly and the underlying provider supports windows authentication. Depending on the infrastructure and communication paths, you may need to set up Kerberos Delegation to allow the K2 server to impersonate the user when connecting to the provider.

SSO

The SSO mode uses an encrypted store of user "keys". A user should set up their alternate credentials in K2 workspace before this approach will be used. When SSO is used, K2 will check the encrypted "keys" store and obtain the connected user's security token for the target provider. K2 will then connect to the provider with this alternate token, without the user needing to provide their alternate credentials for the target system again.This mode usually requires that a Security Provider and Label have been defined for the target system and that the user has cached their credentials for the target system, so that K2 can perform the necessary conversion between credentials.

Consider the diagram for this topic. Suppose that an Active Directory user is attempting to execute a method for a Salesforce-based SmartObject. Because Salesforce does not accept an Active Directory token, we've configured a SSO provider for Salesforce using the Salesforce: security label. Before connecting to Salesforce, K2 will check the SSO store for the current user's encrypted Salesforce username and password, and then connect to Salesforce with these alternate credentials. As far as the user is concerned, they don’t even know that K2 performs this credential-conversion in the background.

The screenshot below shows where users can maintain their stored credentials in K2 Workspace.

Maintaining alternate SSO credentials in the K2 Workspace

Static

Static credentials allow you to configure a specific username, password and optional "extra data" that will be used to connect to the underlying provider. This approach is useful when the underlying provider uses some authentication mechanism other than Active Directory, and you can use a static username and password to connect to the provider.

In your Service Broker code you would retrieve the settings for the username and password and then connect to the provider with these values. Note that this approach is used when it is not necessary to secure the data based on the connected user, because all calls to the provider will be performed in the context of the static user account, not the context of the connected user.

OAuth

This option is used when the target system supports OAuth and you want to enable K2 to pass OAuth credentials for the currently-connected user to the target system. It is a form of impersonation and SSO since K2 performs the necessary negotiation and authentication calls to obtain a security token for the currently-connected user from the target system.

This authentication mode requires that an OAuth resource instance with all of the supporting redirects, refreshes and trusts are configured. You can learn more about the required resources in the KB article http://help.k2.com/kb001702#How to configure OAuth in K2.

Summary

• When you register a Service Instance you need to tell K2 what authentication mode to use
• The authentication mode determines what credentials are passed to the target system at runtime

Authentication Mode	Behavior	Usage
ServiceAccount	The K2 service account’s credentials will be used when connecting to the provider.	This is the simplest option when Active Directory authentication is used and the provider does not have high security requirements. Any interaction with the provider will use the K2 service account.
Impersonate	The currently-connected user’s credentials will be used to connect to the external system.	This option will pass the credentials of the user currently connected to K2 to the provider. This is often used when the provider implements user-level authorization and the data must be protected against unauthorized access. This option could be more complex to implement if Kerberos or K2 PTA is used to persist the user’s security credentials across machine or network boundaries.
SSO	Uses a Single Sign-On credential caching mechanism to pass stored user credentials to a provider.	This option is typically used when the provider uses a non-Active Directory authentication mechanism. Users will cache their credentials for the provider in the K2 SSO store, and K2 will then use these stored credentials to connect to the provider.
Static	Uses a hard-coded, static username and password combination to connect to the provider.	K2 will use a specific username and password to authenticate with the provider. This option is most often used when the provider does not support Active Directory authentication, or when any interaction with the provider must occur as a specific user.
OAuth	K2 will leverage OAuth to obtain an authentication token for the currently-connected user, and then pass that token to the provider.	Requires that the Service Broker and the target system supports OAuth and the necessary OAuth resources and trusts have been set up.