...
You can integrate Kiuwan with a Local Authentication system.
This is a common scenario in organizations that validate their employees' credentials against their own authentication system, and do not want them to use other credentials when accessing external services.
If your company uses a corporate authentication service, your users and passwords will most probably be stored in Active Directory, OpenLDAP, IBM Tivoli or any other similar system.
If that is your case, it’s not needed to have different credentials for your Kiuwan account, you can use existing ones.
| Info |
|---|
By integrating Kiuwan with your Local Auth service, you will make Kiuwan authentication to delegate on your own system, avoiding the need to use/maintain |
...
additional credentials. |
Local Authentication scenarios
Depending on your infrastructure, there are at least two possible scenarios:
Centralized Authentication
Do you need to login to every system in your organization using the same user/password ? Are you tired to type the same credentials to access different systems? This is a clue that your organization maintains a centralized authentication system (i.e. your organization is keeping your credentials in a unique system) that is used by the different systems.
Single Sign-On (SSO)
Do you only need to authenticate once and you are able to access the different systems? That is an evidence that your systems are internally using an authentication system that is shared by the different applications, making unneeded to type your credentials when you access those systems. This is what is called a Single Sign-On environment.
If you want to avoid using/maintaining Kiuwan credentials, ask you first which of the above models apply to your organization, and don’t care, Kiuwan supports both !!
| Info |
|---|
Follows |
...
two different mechanisms to make Kiuwan work in a SSO environment.
|
...
|
...
...
|
...
|
...
|
...
...
|
Delegated Authentication Single Sign-On
Centralized authentication is also known as “delegated authentication”“delegated authentication”.
In this scenario, Kiuwan delegates your authentication to an external system, it’s a matter of trust!!
How this can be accomplished? Take a look at the next image.
In this scenario:
Login to Kiuwan
First, you must login to Kiuwan …. but not to www.kiuwan.com !! No, you need to setup an specific URL within your domain. Something similar to http://www.yourdomain.com/kiuwan, http://kiuwan.yourdomain.com or something similar.
Identify user
That URL will be received by an “authentication service application” that will delegate your authentication to an external system, e.g. Active Directory, LDAP or a similar system.
Redirect to kiuwan.com with token
The corporate authentication system checks if you do already have a security context or you need to identify. If the authentication succeeds, the authentication service application will generate a JWT authentication token including the username (encrypted using a secret key that you can generate in your Kiuwan account settings page).
Once the auth token is ready, the system redirects to your browser
Authenticated request
The browser request access to kiuwan.com with an authenticated request that kiuwan.com recognizes, granting access to the requested resource.
You can find a sample authentication service application (kiuwan/kiuwan-local-authentication) as a sample to get started. This sample application uses Tomcat (tomcat-users.xml) as authentication mechanism, but you can freely adapt to any other external auth system.
...
As you have seen during the explanation of Centralized Authentication scenario, you need to provide some authentication service application that generates the auth token based on kiuwan’s provided secret key. Therefore, to use this scenario you must setup this specific app.
| Info |
|---|
A different approach is to use a more advanced approach that makes use of a “standard” mechanism to which most vendors adhere to (SAML’s Single Sign-One)
Since April 2019 release, Kiuwan allows you to login in a SAML Single Sign-One (SSO) environment.
By implementing SSO, a user is able to log in to different independent systems through the use of a single set of credentials, centrally managed in a repository |
...
From a management perspective, SSO model provides a single user account management interface through which all the component/application domains may be managed in a coordinated and synchronised manner.
In a SSO In a SSO scenario, we can define the following actors or participants:
A User requesting for some resource or service
A Service Provider (SP) that receives the request and provides the service or access to the resource
An Identity Provider (IdP) that authenticate the user and asserts the user identity
SSO can be implemented through different protocols, being SAML and OpenId Connect the most widely used.
Kiuwan currently supports SAML and this document serves as a how-to use Kiuwan in a SSO-SAML environment.
In summary, if your organization is using some kind of centralized users’ credentials repository implementing SAML and you want to use those enterprise credentials to authenticate in Kiuwan, this document provides you with information on how to set up Kiuwan to participate in a SSO-SAML environment.
What is SAML?
| Info |
|---|
...
SAML stands |
...
for Security Assertion Markup Language |
...
and it’s |
...
an open standard for exchanging authentication and authorization data between parties. |
...
In particular, between |
...
an identity Provider (IdP) and |
...
a Service Provider (SP). |
SAML is an XML-based markup language for security assertions usually transferred from IdPs to SPs. These assertions are used by SPs to make access-control decisions.
Basically, SAML assertions contains three types of statements:
Authentication statementsstatements
Example: User U has been successfully authenticated at time T using method M of authentication
Attribute statementsstatements
Example: User U does contains value V for attribute A
Authorization statementsstatements
Example: User U is permitted to perform action A on resource R
Besides assertions, SAML defines SAML protocols, i.e. the processing rules to use assertions between SPs and IdPs.
Examples of such protocols are :
...
These SAML protocols can be mapped to standard messaging formats. This mapping is called a SAML binding, examples of such bindings are:
SAML SOAP Binding
HTTP Redirect (GET) Binding
HTTP POST Binding
etc.
Finally, SAML profiles describe in detail how SAML assertions, protocols, and bindings combine to support a defined use case.
SAML 2.0 provides support for many profiles such as:
Web Browser SSO Profile
Identity Provider Discovery Profile
Assertion Query/Request Profile
etc
| Info |
|---|
The most important SAML 2.0 profile is |
...
the Web Browser SSO Profile, and |
...
it’s fully supported by Kiuwan. |
SAML Security requirements
...
In the Web Browser SSO workflow above, there are some interactions between the IdP and the SP that are based on mutual trust, for example:
How does the SP know the IdP is authentic? And in turn, how does the IdP know the SP is authentic ?
How does the SP know where to send the user agent with the auth request? And how does the IdP know where to send the user agent with the auth response?
How does the IdP encrypt the SAML assertion so that the trusted SP (and only the trusted SP) can decrypt the assertion?
How does the service provider know that the auth response is coming from a trusted IdP?
| Info |
|---|
These and other similar “trust” conditions are based on the use |
...
of SAML 2.0 Metadata.
Metadata ensures a secure transaction between an IdP and a SP through sharing of trust information. SAML 2.0 provides a well-defined, interoperable metadata format that entities can leverage to bootstrap the trust process. |
Regarding SSO SAML actor’s identity, metadata are defined for:
Identity Provider metadata (to publish identity information about the IdP itself)
Service Provider metadata (to publish identity information about the SP itself)
Also the endpoints of communication are also defined by metadata, such as:
SSO Service metadata (description of IdP’s SSO endpoint)
Assertion Consumer Service (desc of SP’s service to send assertions from the IdP)
...
How to configure Kiuwan to work with SSO - SAML
| Info |
|---|
As explained before, Kiuwan plays the role of Service Provider (SP) |
...
in a SSO - SAML context. |
To configure SSO in Kiuwan you must first, of course, rely on an existing Identity Provider (IdP). There are many available IdP systems, all of them sharing SAML concepts (more or less adapted to their own terminology).
As seen above, to set up a Web SSO environment, SAML agents (idP and SP) need to be identified and let each other know of their existence.
This step is accomplished by exchanging each other’s metadata.
Kiuwan configuration : How to configure your IdP in Kiuwan
| Info |
|---|
Kiuwan provides an administration page to configure your IdP metadata. |
You can find SSO configuration page at Account Management >> Organization and clicking on Configure SSO button.
Please read carefully the notes:
By activating the SSO in your account, all users of your account will be automatically migrated to your own domain to avoid conflict with other usernames in other Kiuwan accounts.
After this migration, all users of your account must use a new URL for the Login, leaving the login URL that you have been using until now. This new URL will be communicated to you in the next step of this page.
In order to continue using the Kiuwan Local Analyzer, API REST, Kiuwan for Developers, or any other plugin that needs to request for some data to Kiuwan, you must change the configuration and indicate the DOMAIN ID in their respective configuration screens. This DOMAIN ID will be provided when you activate the SSO. (see further sections on these topics)
Once activated the SSO, you must communicate to all your users the new login URL and your DOMAIN ID.
Once SSO is activated, it is NOT possible to disable it or re-migrate users to the previous Kiuwan domain.
Event though the activation process is completed, you will need to register Kiuwan as SP in your IdP. Till then, you can not use SSO. See section on “Kiuwan’s metadata configuration in ADFS”
Clicking on Continue button you can upload you IdP Metadata XML.
In a typical ADFS installation you can commonly get it at: https://<your_idp_domainname>/FederationMetadata/2007-06/FederationMetadata.xml
| Info |
|---|
If your IdP is Azure AD, please be sure to |
...
check My IdP is Azure AD. |
Once it’s loaded, click on Continue button
At this moment, you should have received an email with an activation code as well as Domain Id and Login URL. Enter the activation code and click Activate SSO button.
| Info |
|---|
If you don’t check that option, existing users can still login using user/password, but using the new URL. Older Kiuwan URL will not work any more because all the users have been migrated to SSO.
IMPORTANT: Is your users are using Kiuwan Local Analyzer, DO NOT CHECK THIS OPTION, because all the users will be forced to use SSO. Because KLA still does not fully support SSO, if checked you will need to manually activate user/password auth for all KLA’s users !!
Admin users can ALWAYS login both ways. Other users can be managed individually as using Kiuwan auth or SSO (see Users Administration page). |
If you want to avoid currently existing Kiuwan users to login using former credentials (username and password), check Disable login with password for all my users. By checking this option, all the users will be forced to login through SSO (using the provided URL).
...