User management#

Role-based access control (RBAC) restricts API requests based on the user's role in your organization. Nokia EDA uses the OAuth 2.0 standard for authorization.

Nokia EDA uses Keycloak as the OAuth 2.0 identity provider, authenticating users and group membership. The Nokia EDA API server validates request authorization based on the role(s) assigned to the user's group(s). Roles can also be assigned to service accounts to authorize API access for non-human entities.

Common Keycloak administrative actions including user and user group management, are available via the Nokia EDA API and UI.

Users and user groups#

Nokia EDA users and user groups are stored in Keycloak.

In the Nokia EDA UI, you can find Users and User Groups in the System Administration panel under User Management > User Management.

User passwords set by an administrator can be flagged as temporary; this will prompt the user to change the password on first login. Administrators can also perform password resets, which sends the user an email with a password reset link.

Nokia EDA comes with a default local user called admin. The admin user is assigned to the system-administrator group.

Federations#

Federations configure users and user group synchronization with remote directories such as OpenLDAP or Active Directory.

Nokia EDA supports:

• The configuration of up to five directories
• LDAP and Active Directory directories
• User synchronization from the directory
• Group synchronization from the directory and user group membership mapping
• Limiting imported users and groups using LDAP filters

Federated users are imported into Keycloak the first time a user logs in or when the user list is read via the Nokia EDA API and UI. Additionally, you can configure periodic sync of created and updated users.

In the Nokia EDA UI, federated users are identified in the Federated User field in the users list.

When a federation is configured, system administrators can continue to create local users and groups in Nokia EDA.

The Nokia EDA API server blocks all edits to federated users except for adding or removing the user to local groups. Local changes to federated groups are not supported; federated group membership must be configured on the LDAP server.

When connecting a federation provider using LDAPS or STARTTLS, Keycloak must trust the server's TLS certificate. To add certificate authorities to the EDA Keycloak truststore, create a Kubernetes secret named ldap-ca-secret of type Opaque in the EDA base namespace with a base64 encoded PEM certificate in the ca field. For example:

apiVersion: v1
kind: Secret
type: Opaque
metadata:
  name: ldap-ca-secret
  namespace: eda-system #Enter the base namespace of your EDA installation
data:
  ca: <base64 certificate> # Base64 encoded PEM certificate

Nokia EDA monitors this secret and if it changes, Nokia EDA updates the certificate authority information used by Keycloak. Modifying the authority information results in a restart of the Keycloak server.

Password policies#

The system enforces a password policy for local users. The password policy does not apply to users authenticated from remote directories or service accounts.

The password policy options include password aging rules, password complexity rules, password history, and user lockout rules. An admin user can update the policy settings as needed. The policy also applies to the admin user.

User Sessions#

Keycloak maintains a list of active sessions. Each session is associated with a short-lived access token, and a longer lived refresh token.

Session information includes:

• Username
• Start time
• User's source IP address
• Clients (for example, the Nokia EDA UI)

From the Nokia EDA API and UI, you can:

• View a system-wide list of active sessions
• View a per-user list of active sessions
• Logout a specific session

Service accounts#

Service accounts are non-human identities used by applications, controllers, and automation systems to access Nokia EDA APIs. Unlike user accounts, they do not use a username and password or any interactive login steps such as one-time-passward (OTP) or web browser redirect.

A service account is an Oauth client using the Client Credentials grant type, typically authenticating with a client id and client secret¹. Nokia EDA ClusterRole and Role resources are assigned directly to the service account for managing permissions.

You can create, edit, and delete these clients, and assign roles to service cccounts from the Nokia EDA UI and API.

Roles#

Nokia EDA ClusterRole and Role resources define permissions for users and for service accounts.

Roles define permissions within a specific namespace, whereas Cluster Role permissions apply to all namespaces.

Non-namespaced Nokia EDA API endpoints can only be enforced by Cluster Roles. This includes cluster-wide resources (for example, LogOutputs), Nokia EDA administrative APIs, and transaction results. In general, any API that does not specify a namespace in the path or payload is enforced by Cluster Roles.

For ClusterRole and Role, the following rule types are supported:

• Resource Rules: defined Nokia EDA resource and workflow permissions using Group-Version-Kind (GVK) semantics.
• Table Rules: defines permissions for queries to EDB.
• URL Rules: defines permissions for Nokia EDA API endpoints based on their URL path. URL Rule permission is not required for API endpoints which are Resource Rule or Table Rule enforced.
• Core access items: defines permissions for access to Nokia EDA platform capabilities that are not associated with a specific EDA resource, or EDB table.

You can assign ClusterRole and Role to user groups and to service account clients.

Resource rules#

Resource rules define access to Nokia EDA resources and Nokia EDA workflows. These rules are relevant for resource-aware Nokia EDA API endpoints including:

• /core/transaction/..
• /apps/..
• /workflows/..

A resource rule is defined by the following parameters:

• API groups: Identifies the Nokia EDA API groups for the resources controlled by the rule, in the format {group}/{version}.

  An asterisk * indicates wildcard of any API group. A * wildcard can also be used for the group version, for example, core.eda.nokia.com/*.

• Permissions: Specifies none, read, readWrite, or readPropose permissions for the Nokia EDA resources matching the rule.

  readPropose allows users to dry-run transactions, create merge requests, and commit in a branch. It does not allow the user to commit directly to the main Nokia EDA cluster.

• Resources: The resource names of the resources controlled by the rule. For example toponodes.

  An asterisk * indicates wildcard, which means match any resource in the specified API group.

Table rules#

Table rules are similar to resource rules, except that they are relevant to the API endpoints used for querying the Nokia EDA database (EDB). A table rule is defined by the following parameters:

• Path: Specifies the path of the database table for which this rule applies.

  Table Rules support wildcarding of the final Nokia EDA path segment (.*) or multiple Nokia EDA path segments (.**)

• Permissions: Specifies none, read, or readWrite permissions for the EDB table.

  readWrite access is not relevent for EDA UI and REST API users. This permission is intended for controller applications using service account authentication for internal EDA gRPC services.

URL rules#

URL rules define generic enforcement of URL paths exposed by an API server.

• Path: Specifies the API URL path to which this rule applies.

  /* at the end of the path indicates the final portion of the URL path can be anything, if the prefix matches.

  /** at the end of the path indicates that the URL path can be anything if the prefix matches.

• Permissions: Specifies none, read, or readwrite permissions for the URL path.

Core access items#

Core access item rules define access to Nokia EDA platform capabilities that are not associated with a specific EDA resource, or EDB table.

Core access items use a {item}/{optional subitem}/{verb} structure. Examples: alarm/read, transaction/restore, aaa/user/write.

Wildcarding is supported:

• *: Matches all core item permissions, for example for the system-administrator role.
• */read: Matches all core item permissions that use the read verb.
• */write: Matches all core item permissions that use the write verb and write-equivalent actions.
• {item}/*: Matches all permissions under an item, including subitems. A single * is recursive. For example, aaa/* matches aaa/user/read, aaa/group/write, and other aaa permissions.
• {item}/{subitem}/*: Matches all permissions for a subresource. For example, aaa/user/* matches aaa/user/read, aaa/user/write, and aaa/user/resetpassword.

Multiple rule behavior#

Nokia EDA rules are additive. Users are granted the combined permission of all rules in the roles assigned to their user groups. If a request does not match any rule, it is implicitly denied.

The None permission acts as an override; these are enforced before any other rule.

Examples#

apiVersion: core.eda.nokia.com/v1
kind: ClusterRole
metadata:
  name: system-administrator
  namespace: eda-system
spec:
  coreAccessItems:
    - '*'
  description: This is the default administrator role for EDA. It cannot be deleted.
  resourceRules:
    - apiGroups:
        - '*'
      permissions: readWrite
      resources:
        - '*'
  tableRules:
    - path: .**
      permissions: read
  urlRules:
    - path: /**
      permissions: readWrite

kind: ClusterRole
metadata:
  name: basic
  labels: {}
  annotations: {}
spec:
  description: ''
  resourceRules:
    - apiGroups:
        - core.eda.nokia.com/v1
      permissions: read
      resources:
        - '*'
    - apiGroups:
        - fabrics.eda.nokia.com/v1
      resources:
        - fabrics
      permissions: readWrite
    - apiGroups:
        - fabrics.eda.nokia.com/v1
      resources:
        - '*'
      permissions: read

apiVersion: core.eda.nokia.com/v1
kind: Role
metadata:
  name: ns-admin
  namespace: eda
spec:
  coreAccessItems:
    - '*'
  resourceRules:
    - apiGroups:
        - '*'
      permissions: readWrite
      resources:
        - '*'
  tableRules:
    - path: .**
      permissions: read
  urlRules:
    - path: /**
      permissions: readWrite

apiVersion: core.eda.nokia.com/v1
kind: ClusterRole
metadata:
  name: readonly
  namespace: eda-system
  labels: null
spec:
  coreAccessItems:
    - '*/read'
  description: Read only for everything
  resourceRules:
    - apiGroups:
      - '*'
      permissions: read
      resources:
        - '*'
  tableRules:
    - path: .**
      permissions: read
  urlRules:
    - path: /**
      permissions: read

apiVersion: core.eda.nokia.com/v1
kind: ClusterRole
metadata:
  name: fabric
  namespace: eda-system
  labels: null
spec:
  description: Read and Write for Fabrics and read-only for related resources
  resourceRules:
    - apiGroups:
      - fabrics.eda.nokia.com/v1alpha1
      permissions: readWrite
      resources:
        - '*'
    - apiGroups:
        - routing.eda.nokia.com/v1alpha1
        - protocols.eda.nokia.com/v1alpha1
        - core.eda.nokia.com/v1
      permissions: read
      resources:
        - '*'

apiVersion: core.eda.nokia.com/v1
kind: ClusterRole
metadata:
  name: queryandalarms
  labels: null
  namespace: eda-system
spec:
  coreAccessItems:
    - 'alarm/*'
  description: 'Permission to run queries and update alarms (ack/delete/suppress/etc)'
  tableRules:
    - path: .**
      permissions: read

apiVersion: core.eda.nokia.com/v1
kind: ClusterRole
metadata:
  name: topology-definitions
  namespace: eda-system
spec:
  description: Access descriptions of physical topology and its overlays
  resourceRules:
    - apiGroups:
        - topologies.eda.nokia.com/v1alpha1
      permissions: read
      resources:
        - topologygroupings
  urlRules:
    - path: /core/topology/v1
      permissions: read
    - path: /core/topology/v1/topologies.eda.nokia.com_v1_physical
      permissions: read
    - path: /core/topology/v1/topologies.eda.nokia.com_v1_physical/overlay
      permissions: read
    - path: /core/topology/v1/topologies.eda.nokia.com_v1_physical/groupings
      permissions: read

apiVersion: core.eda.nokia.com/v1
kind: Role
metadata:
  name: ns-topo
  namespace: eda
spec:
  description: Access physical topology state in namespace 'eda'
  urlRules:
    - path: /core/topology/v1/topologies.eda.nokia.com_v1_physical/state
      permissions: readWrite

User management in the Nokia EDA UI#

Users page#

The Users page in the UI lists all local and remote Nokia EDA users and provides a summary of user details. You can sort and filter for users using the typical mechanisms.

Creating a new local user#

Managing user accounts#

Managing user sessions#

To display all user sessions, from the System Administration navigation panel, expand USER MANAGEMENT and select User Sessions.

• To filter sessions for a specific user, enter the user name in the filter box.
• To terminate a session for a user, click the Table row actions menu and select Logout.

Changing your password#

Perform this task from any page on the Nokia EDA UI.

Viewing user groups#

From the System Administration navigation panel, expand USER MANAGEMENT and click User Management. Select User Groups from the drop-down list.

Creating a user group#

Deleting user groups#

Configuring a federation #

Deleting a federation #

Modifying the password policy#

Creating a cluster role #

Creating a role #

The Role resource defines a set of permissions to access Nokia EDA resources. The Role resource exists within a namespace.

Viewing service accounts#

From the System Administration navigation panel, expand USER MANAGEMENT and select User Management. From the User Management drop-down list, click Service Accounts.

The Service Accounts page lists service account clients and the following client settings:

Creating a service account#

After you save, the system displays the client secret. Copy the client secret and store it securely. You cannot view the secret again from the list; open the service account to reveal, copy, or regenerate it.

Managing a service account#

Regenerating a client secret#

Regenerating the secret immediately invalidates the previous secret. Applications that still use the old secret cannot authenticate until you update them.

Deleting a service account#

Privacy considerations#

From a privacy perspective, Nokia EDA stores user information securely in a database. This information includes the username, password, email, first name, last name, and login times of each user in the system. Additionally, user activity is logged securely for security and support perspectives. The information is not processed or shared outside of the deployed Nokia EDA environment. A backup contains the same information for the purpose of restoring the users if a restore is required.