Authentication

How it works

K2 uses a primary identity and a secondary identity.

• The primary identity provides the logged on user with authenticated access to the K2 Server.
• The secondary identity is used to authenticate the current user against a security label.

You log onto the K2 Server using your primary identity. When you execute a BAPI (which uses the K2 security provider mechanism) you are prompted to cache secondary credentials if a valid set is not available.

The Primary set of credentials are cached in the Credentials Cache table against the K2 security label. The secondary set of credentials are associated with the primary set along with the relevant security labels. If your credentials are changed by the administrator, the process described here will be repeated, overwriting the existing secondary set of credentials.

First Time Login

When you log in for the first time, the following takes place:

1. You log on to the Server with primary credential set using a K2 label. This will use SSPI to authenticate you in the client OS.
2. Once authenticated on the server, your primary identity is logged and persisted in the credential cache.

SAP Access

The process of accessing SAP to run the SAP BAPI involves a number of steps. These steps require interaction and authentication between K2, the selected user manager (in this scenario, Active Directory) and SAP. Using K2 connect for SAP to authenticate a user is the same in principle as using the SAP GUI. The steps are provided in point form to simplify and help in explaining how it works. If a further and deeper discussion of this is required, please consult the K2 Five documentation.
The following assumptions are made:

• A custom ASPX form is used.
• You want to streamline authentication by adding custom code to your custom form.

Authentication	Type	Description
Authentication Method	Windows Authentication	If you are using integrated security for the database connection between the Server and the database, the account must have rights on the K2 connect database. SSO and Static authentication between K2 connect and SAP are supported.
Single Sign On	Credentials Cache	Each user, developer or workflow user requires a second set of credentials to sign on to SAP for BAPI access.
Service Instance Authentication	Static	This method enables the credentials of the Service Instance to be used.

Cache User Credentials Options

Automated Method: The automatic method requires that a portion of code be added to your custom form. This enables the form to handle the exception when it is received from the K2 Server. The user can be prompted to supply a valid set of secondary credentials then. This method is better suited for streamlining the process of caching credentials since it can be performed from the form, without the need for the user to use K2 Workspace.

Design-time Authentication vs. Runtime Authentication

K2 connect security is handled differently in Design time vs. Runtime. (Design time refers to the Service Object Designer and Test Cockpit tools in Visual Studio which you use to create connect Service Objects, while Runtime refers to SmartObjects being executed by users and SAP-enabled applications).

Design-time authentication

You may choose to include predefined security credentials in the connect Destination connection string. If no security credentials were supplied in the connection string, you are prompted to enter SAP credentials whenever you explore the target SAP system with the Service Object Designer or the Test Cockpit tools.

If static credentials were used and you select the option to use Predefined User Credentials, the list of BAPIs will be the same for all developers. If the developer provides credentials themselves, the list of available BAPIs may be filtered based on SAP security. Use the approach which best suits your organization's security requirements.

Prompt to enter credentials at design time. Note the option to use Predefined User Credentials

You need permission to remotely restart the K2 connect service, because as part of the deployment process the K2 connect service may be restarted to load the updated definitions. By default the local administrators security group in Windows has this permission, but if you want to give others the right without adding them to the local administrators group, see the following Microsoft KB article: http://support.microsoft.com/kb/325349.

Only RFC-enabled BAPIs are available. Your SAP administrator will know how to enable RFC for function modules in your specific environment. To register a remote function module in SAP, the SAP administrator needs to register the module as remotely-callable in the RFC server system, using the function module Administration screen (transaction code SE37). They should set the BAPI to be remote-enabled. For more information, refer to the SAP documentation. A screenshot of this setting in a SAP R/3 system is shown below.

Enabling a BAPI for remote access

Runtime Authentication

Runtime authentication is configured per Destination and the settings are applied to the Service Instance for the Destination. We recommend using the K2 connect administration tool to update the Runtime security for a destination, but you may need to update the security setting manually if multiple Destinations are configured.

You have three approaches to Runtime authentication for K2 connect: Static Credentials, K2's internal Single Sign On (SSO) provider or a SAP SSO mechanism based on SAP Logon Tickets.

To configure the Runtime security for a connect Destination with the K2 connect administration tool, click K2 settings and then select the appropriate authentication mechanism from the radio buttons.

Option	Behavior
Static Credentials	Enter a static SAP username and password. All communication between K2 and SAP will happen in the context of this account, so essentially all users will have the same level of access and SAP will not have context of the user requesting the data. This option is mostly used when you are working with a lookup SAP system, or where user-level security is not required. Behind the scenes, the Service Instance is set to use Static authentication and the username and password is encrypted and stored in the Service Instance.
K2 SSO	This option utilizes the K2 Single Sign-On mechanism to cache and resolve user credentials for SAP at runtime. Users will need to maintain their cached user credentials in the K2 Workspace tooling and specify the SAP destination name that the credentials are used for. Alternatively, developers can write code to perform the caching automatically via a custom login form.
SAP SSO	With the SAP SSO approach, K2 requires that users pass a SAP Logon Ticket as a parameter whenever they call a SmartObject method. The Logon Tickets are obtained from a SAP system (for example a SAP NetWeaver portal). See this K2 KB article for information on using SAP SSO: https://community.nintex.com/k2-blackpearl-66/k2-connect-for-sap-security-enhancement-sap-sso-support-2530 See this SAP article for more on using SAP SSO Logon Tickets: http://scn.sap.com/docs/DOC-17126