Authorization and Authentication Concepts

Before you can start figuring out the best setup for your organization, it’s important to understand the difference between authentication and authorization.

In simple terms:

While we recommend using a security protocol for managing users and permissions, the IQ Server realm is also available for those who need a lighter setup. Using a local setup (IQ Server realm), user accounts, including usernames and passwords are created and managed on the IQ Server itself.

A local setup can be used for both authorization and authentication. This is the simplest option when you have a limited number of users and you’re using our local database – good for evaluations, or for very small teams of less than a dozen total individuals.

The most common, and preferred, method of authentication and authorization is using your company’s existing Lightweight Directory Access Protocol (LDAP) server. If you have LDAP, you’ve already mapped the users and groups, and it is much easier to use that existing information with IQ Server.

In addition to handling authentication via LDAP, the IQ Server can be configured to map roles to LDAP user groups. If a user is a member of an LDAP group associated with an IQ role, the IQ Server grants that user the matching role permissions. In addition to this highly configurable user and group mapping capability, the IQ Server can augment LDAP group membership with specific user-role mapping.

All these features allow you to adapt to any specific LDAP usage scenario and take advantage of the central authentication set up across your organization.

Example Scenario

Imagine that your organization has LDAP with no constraints, and you want to use that for IQ Server authentication and authorization. Once it's set up, here's how that scenario would play out.

1. A user requests access to an IQ Server application through their web browser.

2. The IQ Server requests your organization's configured LDAP server.

3. The LDAP server verifies the user’s identity (authentication).

4. After authenticating the user, IQ Server then uses the account's LDAP group attributes in combination with role mappings defined in the IQ Server to determine which features the user is authorized to access (authorization).

5. Users are signed-in with the correct permissions.

Security Assertion Markup Language (SAML) lets users login to applications will credentials pulled from another context. SAML works by sharing a user’s identity in one location (an identity provider) to another (a service provider). Single sign-on via SAML is configured in IQ Server by a system administrator using the system preferences menu or the SAML REST API.

Example Scenario

Imagine that you are deploying IQ Server via AWS and you need to use an identity provider for single sign-on (SSO). Once it's set up, here's how that scenario would play out.

1. Users request access to an IQ Server application (i.e. Lifecycle) through their web browser.

2. The IQ Server requests your organization’s configured identity provider.

3. The identity provider verifies the user’s identity (authentication).

4. If configured, the identity provider can send the user’s groups to IQ Server as an attribute, whose name IQ Server is configured to recognize.

5. After authenticating the user, role mappings (from the user’s username/groups to IQ Server roles) defined in the IQ Server are used to determine which features the user is authorized to access.

6. Users are signed in with the correct permissions.

A reverse proxy is a kind of server that sits between a user’s browser and the IQ Server. The reverse proxy can add additional information to a request on behalf of the client. You need a reverse proxy server to use e.g. OAUTH with IQ Server.

Using a reverse proxy with IQ Server lets you do the following:

The IQ Server can be configured to accept a reverse proxy configuration.

Example Scenario: LDAP with SSO

Imagine that your organization has an existing LDAP, but needs single sign-on with IQ Server. You decide to set up a reverse proxy server to implement SSO. Once it's set up, here's how that scenario would play out.

1. Users request access to an IQ Server application through their web browser.

2. The web browser talks to the reverse proxy.

3. The reverse proxy delegates to your SSO service for authentication.

4. The SSO service says either “yes, good to go” or “nope, and here’s the error.”

5. If yes, then the authentication request gets sent off to the IQ Server with the username header populated.

6. For authorization, users are given permissions based on LDAP groups associated with roles in the IQ Server.

In this example, the single sign on server is used for login/authentication, but the association of permissions is still done via LDAP groups.

Example Scenario: OAuth

Imagine that you are deploying IQ Server via AWS, so you need to use a reverse proxy server to work with an OAuth service for user authentication and authorization. Once it's set up, here's how that scenario would play out.

1. Users request access to an IQ Server application through their web browser.

2. The web browser talks to the reverse proxy.

3. The reverse proxy delegates to your OAuth service for authentication and authorization.

4. The OAuth service says either “yes, good to go” or “nope, and here’s the error.”

5. If yes, then the authentication request gets sent off to the IQ Server with the username header populated.

6. For authorization, because the user came from an OAuth service, the IQ Server assumes that the user has access to whatever the *All Authenticated Users* group has access to.

With OAuth, it's important to understand that all authentication and authorization are done externally. The IQ Server does not have any integration with OAuth to pull those permissions out. OAuth only passes along the username header. There is no group header available. There is currently no group mapping between IQ Server group roles and OAuth groups.

Remember that the Authenticated Users group in IQ Server is available for the OAuth service, and provides a way to grant permissions to any authenticated user. Using this method is more of a blanket approach and does not let you differentiate between roles like owner and developer. For example, let’s say all of your developers access IQ Server through OAuth and you want to easily give them developer permissions. In this case, you would use the *Authenticated Users* group in the IQ Server realm to say that all authenticated users are developers. You may then grant owner access to specific individual users.

If you’re not using LDAP, you can assign roles to individual users or groups of users in the IQ Server realm. IQ Server has a built-in group called Authenticated Users that contains any authenticated user. This is not an LDAP group, but rather an internal group that is built-in to IQ Server.

The Authenticated Users group is available for any type of authentication/authorization service (SAML, OAuth, etc), and provides a way to grant permissions to any authenticated user.

As a general tip, if you want more defined groups than “all authenticated users,” your best bet is to set up an LDAP server and connect it to the IQ Server.

User Tokens

In the context of authentication and authorization, a token is an object that substitutes for a user's credentials. Tokens contain proof of a user's identity without requiring the user to expose their credentials, which may be desirable if the user is using their credentials elsewhere.

Tokens are also easy to create and delete, which can support security policies that require credential updates (e.g. changing your password once every quarter). It also helps for eventualities where credentials are lost. This also means that tokens permit others to work on behalf of a user without the user needing to reveal their credentials. Once the work is done, the user can immediately delete their old token and create a new one.

In practice, user tokens in IQ server take the place of a username and password. For example, instead of beginning a REST API request withcurl -u [username]:[password], a user with a token could usecurl -u {tokenusercode]:[tokenpasscode]. The user could also use that usercode and passcode to log in to the browser UI.

Internal, LDAP, and SAML users can all use tokens, and can even create their own tokens using the REST API.

Determining the authentication and authorization methods to implement depends on many factors, and is determined on a case-by-case basis. Ultimately, how you set up your IQ Server is up to your organization, but we can provide some assistance.

Answer the following questions to get started determining which setup may be right for you:

The table below may determine what's required for each method.