Authentication and Authorization

Introduction

K2 authenticates the current user name against an identity store which authorizes that user (or system account like one used by the K2 server) to perform actions within the K2 platform.

In the past, K2, like most platforms built on Windows, required and essentially assumed an Active Directory (AD) from which to retrieve a user's identity. User authentication happened behind the scenes and, as long as you were a valid user with rights, you could do things like impersonate and act on the user's behalf. Then when Windows switched to Kerberos as the more secure, default mechanism, K2 administrators had to understand and configure a lot more trusts and constrained delegations than they were used to. To alleviate some of this, K2 introduced Pass-Through Authentication (PTA) which was used in cases where Kerberos wasn't entirely necessary or was simply overkill, and got K2 administrators out of the business of configuring their environments for Kerberos.

Beyond Kerberos, the internet and widely-used sites and applications, such as Facebook, Twitter, and the like, forced the Windows world and platforms built on Windows, to work with those other systems across standard internet ports of 80 and 443 (a.k.a. HTTP and HTTPS). This, along with the drive to put Office in the cloud, resulted in Microsoft introducing authentication mechanisms in its products that could interoperate with other providers on the internet.

Authentication options for K2

Out of the box K2 has always included the ability to install and work with a user source other than AD, which was and is SQL Server. K2 users don't have to belong to AD as long as you point K2 to user information stored in SQL. SQLUM (the abbreviation for SQL User Manager) is the security label associated with users from a SQL identity store, just like K2 is the label associated with AD users.

K2 also supports other user managers, including a custom UM, so technically K2 could understand user information from any identity store.

Before the introduction of SharePoint 2013, K2 integration with SharePoint required components (WSP solutions) to be installed on every SharePoint server in the farm. While this required extra installation and configuration time, it also meant that the K2 logic and assemblies were part and parcel of the SharePoint domain and could pass user context and data to the K2 server as necessary without the need to independently verify the SharePoint user.

SharePoint 2010 introduced an authentication mechanism different than Windows / NTLM, namely claims-based authentication (CBA). With SharePoint 2013 (as well as SharePoint 2016), even if your network runs Windows / NTLM, your tickets from SharePoint 2013 are Windows identities wrapped in a claims token, and this is the default mechanism for how SharePoint handles identities. Claims tokens from SharePoint are sent in specially-formatted XML called SAML. So when referring to a claims token from SharePoint or K2, they are SAML tokens. Other formats are out there but not supported by SharePoint or K2.

Any system that needs to do something with users coming from SharePoint must at least be able open (sometimes referred to as crack or resolve) the claims token to figure out who the user is, and more importantly, where they're coming from. K2 introduced the claims-cracking logic for SharePoint 2010 integration while maintaining the standard NTLM-based authentication for those users staying in previous versions of SharePoint.

For information on K2 and SharePoint authentication, see the topic: SharePoint Integration with K2.

---