UAA Service Overview

User Account and Authentication is a security service available in the Predix marketplace.

The User Account and Authentication (UAA) service is the primary authentication service on the Predix platform. It enables developers to add user authentication and authorization capabilities to their application. Application developers can obtain a UAA instance from the Predix marketplace and configure the instance to authenticate trusted users and clients for their application. UAA service offers a virtual OAuth2 server to customers to issue and validate tokens for client applications.

UAA Application or Predix UAA allows Predix customers and developers to create virtual UAA instances with the available controls and configurations. Each UAA instance acts as a separate OAuth server. Predix UAA also offers a UAA Dashboard to manage the UAA instance administrative activities, RESTful endpoints, and a command line (UAAC) tool.

UAA includes the following features:

• Identity management through SCIM APIs.

• A complete OAuth 2.0 authorization server.

• Login and logout services for UAA authentication.

• SAML federation capabilities to meet third-party SAML identity provider requirements.

The UAA Server supports the APIs described in the open source UAA documentation .

The following topologies are supported for using the UAA service:

• Local identity management in the User Account and Authentication (UAA) server.
• Federated identity management.
• Federated identity management with additional identity management using UAA. In this topology the users are white-listed based on setup in federated identity store and UAA.

The following diagram shows how authentication in local identity management in the User Account and Authentication (UAA) server.

In this flow:

1. An administrator provisions the users through SCIM APIs in UAA.
2. An application user requests data using a browser.
3. The web application sends the authentication request to UAA. If the user is set up in UAA, the authentication request is approved, the user is authenticated, and the token is issued to the web application. If the data request already contains a valid token, this step is not required.
4. The web application passes the data request and JWT token to the web services.
5. Once the user is authorized, the data is returned to the web application.

The following diagram shows how UAA integrated with federated identity management.

In this flow, instead of performing local authentication using UAA, the users are authenticated using the federated identity store.

The following diagram shows UAA integrated with federated identity management in conjunction with local identity management.

This flow demonstrates authentication using both the UAA service and the federated identity service. The UAA uses the SAML request to communicate with the federated identity services. When an authentication request is generated for UAA, UAA checks the users against the UAA and the federated identity store. This setup is useful for whitelisting the users that can be authenticated. For example, if an organization has a large set of users set up in their federated identity store, but they want only a subset of users to be able to access the services, then they can use this setup to identify the user subset.