Identity Access and Management

1. Introduction

Identity Access Management (IAM) is a user management system which allows administrators to define tenants, users, user roles and user groups within TCUP. It is also for creation of resource access policies. It allows resource access policy enforcement points, such as API gateways, to access the defined policies during enforcement. It allows users to be authorized when they try to access and use any registered resource.

../_images/IAM.jpg

1.1 Intended Audience

The intended audience of this document is anyone who wants to have an overview of TCUP IAM Service. After reading this document user will understand the capability of TCUP IAM Service.

2. Key Concepts

In order to use the Identity Access and Management Service, a user needs to understand some of the basic concepts and building blocks of IAM Service. Please refer to the following section for the concepts:

2.1 TCUP Platform Admin (referred simply as “Admin”)

Every TCUP installation has at least one user defined once the installation is complete. This user is called “Admin”. The “Admin” user can only be created by host operating system administrators having special privileges. The “Admin” user is a super user and it is used for platform administration and tenant creation.

2.2 Tenant Admin (referred simply as “Tenant”)

TCUP is a multi-tenant platform. Data and resources are partitioned on a per tenant basis. Each tenant is administered by a tenant specific administrator called “Tenant”. The “Tenant” user is created by the “Admin” through the TCUP administration portal. The “Tenant” user has complete and unrestricted access to all the allowed resources in their TCUP account. This user creates other less privileged users under the given TCUP tenant.

2.3 User

Under each TCUP tenant, users need to be created. This is done by the tenant admin, i.e. “Tenant” For each created user, fine grained access control policies can be defined within the IAM service. All users have their own credentials (username and password) and API keys to access authorized services.

2.4 Role

TCUP IAM Role is collections of similar policies (set of permissions). “Tenant” can create a role definition and the role can be attached to any user or group. For example an administrator role can have all the access privileges whereas a developer role might not have access to certain services.

2.5 Group

IAM Group is a collection of users who have similar responsibilities or who need similar privileges to use TCUP. For example admin groups have the service permission for Admin activity. Similar examples are developer group, tester group, QA group. A user can be in many groups.

2.6 Service

Service can be defined as an individual resource inside TCUP platform or can also be considered a single micro service. For example sensor observation can be considered a service. These service details need to be registered with IAM and each service consists of multiple permissions to access particular resources.

2.7 Permission

Permission is an access control for a particular service. In IAM, URL based permission is supported. Permission must belong to any of the services created in IAM.

2.8 Policy

Policy is a service access control agreement between a user and authorization end point (IAM). By default a user is denied access to any resource until permission is published into the policy document. Policy document is a combination of various services along with their permissions.

2.9 Active Directory (AD) User

These are the users who are already registered in some other client directory and we want to give them the access by adding them to our IAM. When we add an AD user to IAM with their existing ID and password all their services, roles, group etc. would be null and we would have to give them the access afresh.

3. Functional Capabilities

Identity Access and Management Service have the following functional capabilities:

Admin

  • Create and delete tenants, role, group, policy, permission and service

  • Complete access to the portal

  • Assign/detach role/group to tenant

  • Attach/detach service with permission

  • Attach/detach policies to service

  • Attach/detach role/group to policy

  • Attach/detach role with group

  • Service activation

Tenant

  • Create/delete users/role/policy/permission/service

  • Assign/detach role/group to tenant

  • Attach/detach service with permission

  • Attach/detach policies to service

  • Attach/detach role/group to policy

  • Attach/detach role with group

  • Service activation

User

  • Users cannot create/delete any elements in IAM. They can get a view of the roles, groups and policies assigned to it, if any.

Role

  • Create user role list

  • Get all users by role

  • Detach user from role

  • Detach role from user

Group

  • Get all group

  • Get group by ID

  • Create/update/delete group

4. Purpose/Usage

TCS Connected Universe Platform is a multitenant platform that requires multiple access controls from a user’s perspective. A user requires valid credentials to authenticate themselves and to get the permission to access TCUP services. IAM enables fine access control policies to be created and maintained. One important thing to note is that while IAM service is used internally within TCUP to control access to TCUP services, it can also be used to create policies for access control for resources that are outside of TCUP. For example, resources of an external application can be defined along with necessary polices. IAM APIs can be used to read and update these policies and create enforcement points.

5. Examples

Consider an example of creating a user under a tenant and giving access to TCUP Sensor Observation Service (SOS) to the user. The steps required to create a user under a tenant is as follows:

  1. The tenant needs to log in with their credentials.

  2. The tenant then needs to create a new user by providing a username and password.

  3. SOS access is then given to the newly created user.

  4. The tenant creates a new policy which holds all the SOS permissions.

  5. The tenant then assigns the new policy to the created user.

  6. All the permissions created will be synced to the API gateway. This will allow the API gateway to enforce the policy.

Once the steps mentioned above are followed the newly created user should be able to log in with new credentials and get access to SOS.

6. Reference Document

Please refer to the following documents for more details about this service:

  1. Admin Guide