Authorization and Authentication Concepts

Overview


There are several options for authorization and authentication in IQ Server, and Administrators will need to decide which option works best for their organization. This article helps you make that determination.

The Difference Between Authorization and Authentication

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, authentication determines who you are and authorization determines what you can access.

Authentication is the process of establishing a user's identity. There are lots of methods for determining identity, like user ID and password, fingerprints, facial recognition, and so on. In the context of this topic, a user who is trying to identify themselves is often called a subject.

Authorization is the process of giving a user permissions, usually based on their identity.

When discussing authentication and authorization, it’s also important to note the concept of realms. Realms are a type of database that store the usernames and passwords used to identify and validate users. Realms also list roles associated with each validated user. In both the IQ Server realm and LDAP realm, access to IQ Server resources is granted to all users that have a particular role, and each user can have any number of roles associated with their username.

Option One: Local Users

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.

Example Scenario

Imagine that you're setting up IQ Server to demo Lifecycle scanning for some of your teammates. You want them to be able to log in to explore the UI at their own pace.

To set this up, you'll log in to IQ Server and use the System Preferences menu to create new users. You then need to assign users to access roles in the context of organizations and applications. You can assign a user to either a system-wide administrator role or an organizational role at the level of root organization, organization, or application. Which role and level you choose for a user determines what permissions that user receives.

You can also assign roles to individual users or groups of users. IQ Server has a built-in group called Authenticated Users that contains any authenticated user.

For information on adding users, see documentation about Creating a User. For information on assigning access roles, see documentation about Role Management.

Option Two: LDAP

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 makes a request to 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.

example LDAP authentication flow

LDAP Considerations

When setting up LDAP, keep in mind the following.

  • When authenticating users, IQ Server connects to LDAP servers in the order displayed in the LDAP Servers view. Server order is important, because the first server where a user is found will impact user authentication and/or authorization.
  • A general best practice is to have the group information readily available because when you map an LDAP group to a role, all users in that LDAP group implicitly get the permissions of the role.
  • Keep in mind the benefits of multiple LDAP servers. LDAP Servers can only have one base group DN, which is the point from where a server will search for users. Therefore, if one server has two or more disjointed group DNs, more than one Server definition is required.

Option Three: SAML

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. Nexus Lifecycle) through their web browser.
  2. The IQ Server makes a request to 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.

example SAML authentication flow

Option Four: Reverse Proxy

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:

  • Enable single sign on (SSO) with IQ Server by using a reverse proxy to connect to whatever SSO solution you are employing.
  • Implement external ways of authenticating and authorizing like OAuth.
  • Provide a single point of authentication for all HTTP requests.

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 LDAP with SSO authentication workflow

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 a OAuth service, the IQ Server assumes that the user has access to whatever the *All Authenticated Users* group has access to.

example OAuth authentication flow

With OAuth, it's important to understand that all authentication and authorization is 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.

Group Considerations

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 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 with curl -u [username]:[password], a user with a token could use curl -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 seen here.

Determining Which Method to Use

Determining the authentication and authorization methods to implement depends on many factors, and is determined on a case-by-case basis. In the end, 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:

  1. How many users will you manage?
    • If you have a large enterprise, LDAP is your best option.
    • Local setups should only be used for evaluations and very small teams
  2. Do you already have an LDAP server?
    • If so, then go ahead and use LDAP!
    • If not, determine if implementing one is an organizational priority, or if it will be a priority in the near future.
  3. Do you need SSO?
    • If yes, then you can use SAML.
  4. Do you plan on deploying IQ Server into AWS?
    • If yes, then you will need to use SAML.
  5. Do you need SAML?
    • If yes, then an identity provider is required.
  6. Do you need OAuth?
    • If yes, then a Reverse Proxy is required.

The table below can also help you determine what's required for each method.

MethodEnterprise Solution?Does it Authenticate?Does it AuthorizeDoes it require Other Services?Does it allow for SSO?
Local UsersNoYesYesNoNo
LDAPYesYesYesYes - LDAP ServerNo
Reverse ProxyYesYesNoYes- Authorization ServerYes
SAMLYesYesYesYes - Identity ProviderYes
OAuthYesYesYesYes - Reverse ProxyYes