Configuring Authentication for Services

About Authentication

This section provides instructions for setting up Single Sign-On (SSO) authentication for Unified Inventory and Topology services.

These services implement the Single Sign-On (SSO) authentication solution using OIDC protocol from any supported Identity Provider (IdP), which enables you to seamlessly access multiple applications without being prompted to authenticate for each application separately. The main advantage of SSO is that you are authenticated only once, which is when you log in to the first application and then you are not required to authenticate again when you subsequently access different applications. However, these applications must be with the same (or lower) authentication level (as the first application) and opened within the same web browser session.

These services also support the Single Logout (SLO) feature. If you access multiple applications using SSO within the same web browser session, and then if you log out of any one of the applications, you are logged out of all the applications.

Note:

UIM requires an IdP that supports OIDC.

For more information about how to enable authentication, see UIM Cloud Native Deployment Guide. OIDC is supported for all other services such as Message Bus, ATA, Authorization, SmartSearch and OpenSearch.

Ensure IdP users are assigned below groups for ATA or Service Impact Analysis access:

Groups for UIM:
- uim-users: To access UIM, users must be assigned a role that belongs to the uim-users group. If a user does not have a role in the uim-users group, the following error appears after successful authentication:
```
You do not have permission to access this page. Contact the Administrator.

uimuser: UIM defines the uimuser role (application role in em console). This is a super role that grants access to all UIM resources, so the role should not be granted to everyone. Rather, Oracle recommends that you define your own application roles to restrict access to UIM resources. The uimuser role is part of the uim-users WebLogic Server group. 
```
- SecureDataAccessGroup: To control accessing encrypted data in UIM as follows:
  - Users assigned to the SecureDataAccessGroup role are authorized to decrypt and view encrypted data in UIM.
  - UIM Administrator users who are members of the SecureDataAccessGroup can enter and manage the encryption key within UIM.
  Note:
  You must have the correct encryption key to recover plain text from encrypted data. Back up your encryption key before using the service. If the encryption key is lost, you will be permanently unable to access encrypted data.
- uimuser: The uimuser role is an application role defined in the Enterprise Manager (EM) Console. It is a privileged role that provides access to all UIM resources. Therefore, this role should not be assigned to all users. Oracle recommends creating custom application roles to control and restrict access to UIM resources based on user responsibilities. The uimuser role is associated with the uim-users WebLogic Server group.
  For any new user, ensure the following:
  - The user must be assigned the uim-users WebLogic Server group to access the UIM user interface (UI).
  - The user must be assigned an appropriate application role in the EM Console to access UIM resources.
  For more information, see "Alternative Approach: Group-Based Access Management".
Groups for ATA:
- AtaAdministrator: This group has the privileges of Administrator and AdvancedUser roles. The users with this group can:
  - Create, view, and search topology graphs
  - Edit and delete all saved searches
  - Navigate to all summary pages
  - Create, view, edit, and delete icons and colors customization
- AtaAdvancedUser: This group has the privileges of AdvancedUser role. The users with this group can:
  - Create, view, and search topology graphs
  - Edit and delete saved searches created by the corresponding user
  - Navigate to all summary pages
Groups for Service Impact Analysis:
- SiaAdministrator : This group has the privileges of Administrator, SIA User, and SIA Advanced User roles. The users with this group can edit, reject, assign, and delete all events or impact reports.
- SiaAdvancedUser: This group has the privileges of SIA Advanced User role. The users with this group can edit, reject, assign, and delete events or impact reports for which the current user is the owner.
- SiaUser: The users with this role can:
  - View, search, or filter events
  - View impact summary, initiate analysis, and view entity in ATA or UIM
  - View and export impact reports
  - View resource summary
Groups for Message Reconciliation:
- MessageReconciliationAdministrator: This group has the privileges of Administrator and Viewer roles. The users with this group can edit, delete, rebuild, resubmit, and view all events.
- MessageReconciliationUser: This group has the privileges of Viewer role. The users with this group can:
  - View or search events.
  - View events summary for consumers grouped by error code, actions, or state.
Note:
The Message Reconciliation is a User Interface which is supported by the Fallout Events Resolution RESTful endpoints. These groups are applicable for both User Interface and RESTful endpoints.

To configure authentication for all other services, perform the steps mentioned in the following sections:

Sample references are provided as Appendix, see the following content for the corresponding authentication type:

Alternative Approach: Group-Based Access Management

Instead of assigning roles directly to individual users, you can use a group-based approach:

Create a group in the WebLogic Embedded LDAP.
Assign the required application roles to this group in the EM Console.
Assign the uim-users group to the newly created group to enable UI access.
In your Identity Provider (IdP), create users and assign this group to them.

Note:

Ensure that user and group names in EM Console and WebLogic match those in Keycloak. Keycloak enforces the following naming conventions:

Usernames are stored in lowercase (uppercase input is automatically converted).
Role names are stored with the first letter in uppercase, even if entered in lowercase.

Adding Common OAuth Secret and ConfigMap

To add COMMON OAUTH secret and ConfigMap, run the following script to create the OAuth configuration as secrets and ConfigMap:

$COMMON_CNTK/scripts/manage-app-credentials.sh -p sr -i quick -s $SPEC_PATH create oauthConfig

Enter the values as prompted:

Provide Oauth credentials  for   'sr-quick'   ...
Client Id: topologyClient #Provide Client ID
Client Secret: xxxxx #Provide Client Secret
Identity Provider Uri: <Identity-Provider-Uri>
Client Scope: <oauth-client-scope>  (if scope is not configured for oidc-client keep blank)
Client Audience: <oauth-client-audience> (if audience not configured for oidc-client keep blank)
Token Endpoint Uri: <token_endpoint_uri> #Provide oauth token endpoint URI
Valid Issue Uri: <valid issue uri> #Provide the valid issue URI
Introspection Endpoint Uri: <introspection_endpoint_uri> #Provide the Introspection Endpoint URI
JWKS Endpoint Uri: <JWKS_endpoint_uri> #Provide JWKS Endpoint URI
Cookie Name: <Cookie-Name>
Cookie Encryption Password: <Cookie-Encryption-Password>

Provide Truststore details ...
Certificate File Path (ex. ./idpcert.pem): ./idpcert.pem    #provide Certificate file path

Sample for IDCS is as follows:

Provide Oauth credentials for 'sr-quick' ...
Client Id: xxxxxxxxxxxxx 
Client Secret: xxxx-xxxx-xxxx-xxxx
Identity Provider Uri: https://<IDCS URL>:443
Client Scope: https://quick.sr.topology.uim.org:30443/first_scope
Client Audience: https://quick.sr.topology.uim.org:30443/
Token Endpoint Uri: https://<IDCS URL>:443/oauth2/v1/token 
Valid Issue Uri: https://identity.oraclecloud.com/
Introspection Endpoint Uri: https://<IDCS URL>:443/oauth2/v1/introspect
JWKS Endpoint Uri: https://<IDCS URL>:443/admin/v1/SigningCert/jwk
Cookie Name: OIDC_SESSION
Cookie Encryption Password: <Cookie Encryption Password>

Provide Truststore details ...
Certificate File Path (ex. idpcert.pem): ./idpcert.pem #provide identity provider certificate to be used by Message Bus

Note:

The oauthConfig secret is used by Message Bus, ATA, SmartSearch, and Authorzation services. If you are creating them in different namespaces or instances, you need to create this secret in both namespaces or instances.

Common TrustStore Secret

To add Common TrustStore secret:

Run the following command to create or update truststore by passing the Identity Provider SSL certificate:
```
keytool -importcert -v -alias <param> -file <path to IDP cert file> -keystore <truststorename>.jks -storepass <password>
```
A sample is as follows:
```
keytool -importcert -v -alias idpcert -file identityprovidercert.pem -keystore truststore.jks -storepass ****
```
Note:
You must add the corresponding certificates for UIM and Identity Providers. If the Identity Provider and UIM certificates are not common, add both in the same truststore.

Run the following command to generate commonTrust Kubernetes secret and provide the details appropriately when the system prompts for the truststore file path and password of truststore:

$COMMON_CNTK/scripts/manage-app-credentials.sh -p $PROJECT -i $INSTANCE -s $SPEC_PATH create commonTrust

$PROJECT -> This value should match with the namespace in which you want to run the helm install.
$INSTANCE -> This value should be matching with the instance that you are going to specify while doing the helm install.

Enter the values as prompted:
Truststore Path: truststore.jks
Truststore Passphrase: <passphrase>

Verify the following:

$kubectl get secret -n sr
sr-quick-oauth-credentials

$kubectl get cm -n sr
sr-quick-oauth-config-cm

$kubectl get cm -n sr sr-quick-common-truststore

Note:

The commonTrust secret is used by ATA, SmartSearch, and Authorization services. If you are creating them in different namespaces or instances, you should create this secret in all namespaces or instances.

Common Configuration Options For all Services

You can provide configurations that are common across all services in the $SPEC_PATH/<PROJECT>/<INSTANCE>/config/common/common-config.yaml file and run the commonConfig command.

You can use this option to provide any configuration for ATA (api, ui, impact-analysis-api) and Authorization service. The Mandatory Identity Provider configuration details are passed using oauthConfig secret. If you want to override that configuration or to supply any additional configuration, you can use this option.

Note:

Before running the command, make sure you assemble the specifications.

For more information, see "Assembling the Specifications".

#In case of IDCS as IdP, you have to provide the following additional provider details
security:
  providers:
  - abac:
  - oidc:
  - idcs-role-mapper:
      multitenant: false #update this as per the IDCS instance used.
      oidc-config:
        client-id: "${security.properties.idp-client-id}"
        client-secret: "${security.properties.idp-client-secret}"
        identity-uri: "${security.properties.idp-uri}"
        audience: "${security.properties.idp-audience}"

Add a block for api configuration of users, which is similar to the existing idcs-role-mapper config block. Along with the idcs-role-mapper config, add the folowing configuration to common-config.yaml file:

security:
  properties:
      idp-query-users-scope: "urn:opc:idm:__myscopes__"
      idp-query-users-endpoint: "<Identity provider URI>/admin/v1/Users"
      idp-user-attributes: 
         displayName: "Resources[].displayName"
         userName: "Resources[].userName"
         email: "Resources[].emails[0].value"
         id: "Resources[].id"

3 Configuring Authentication for Services

About Authentication

Adding Common OAuth Secret and ConfigMap

Common TrustStore Secret

Common Configuration Options For all Services