Authorizing object users

The Object Storage service of the IBM Storage Scale system uses Keystone service for identity management. The identity management service consists of user authentication and authorization processes.

Important:
  • CES Swift Object protocol feature is not supported from IBM Storage Scale 5.2.0 onwards.
  • IBM Storage Scale 5.1.8 is the last release that has CES Swift Object protocol.
  • IBM Storage Scale 5.2.0 will tolerate the update of a CES node from IBM Storage Scale 5.1.8.
    • Tolerate means:
      • The CES node will be updated to 5.2.0.
      • Swift Object support will not be updated as part of the 5.2.0 update.
      • You may continue to use the version of Swift Object protocol that was provided in IBM Storage Scale 5.1.8 on the CES 5.2.0 node.
      • IBM will provide usage and known defect support for the version of Swift Object that was provided in IBM Storage Scale 5.1.8 until you migrate to a supported object solution that IBM Storage Scale provides.
      • CES Swift Object is replaced with IBM Storage Scale S3. For more details, refer S3 support overview.
      • For more information about Swift Object in IBM Storage Scale, refer to the IBM Storage Scale 5.2.0 documentation.
  • Contact IBM for further details and migration planning.

Access for the object users to the Object Storage projects are controlled by the user roles and container ACLs. Based on the roles defined for the user, object users can be administrative users and non-administrative users. Non-admin users can do only operations per container based on the container's X-Container-Read and X-Container-Write ACLs. Container ACLs can be defined to limit access to objects in swift containers. Read access can be limited to allow download only, or allow download and listing. Write access allows the user to upload new objects to a container.

You can use an external Active Directory (AD) or Lightweight Directory Access Protocol (LDAP) server or a local database as the back-end to store and manage user credentials for user authentication. The authorization details such as relation of users with projects and roles are maintained locally by the keystone server. You can select the authentication server to be used. For example, if AD is existing in an enterprise deployment and the users in AD are required to access object data, you can decide to use AD as the back-end authentication server.

When the back-end authentication server is AD or LDAP, the user management operations such as creating a user and deleting a user are the responsibility of the AD or LDAP administrator, who can optionally also be the Keystone server administrator. When local authentication is used for object access, the user management operations are done by the Keystone administrator. With authorization, the management tasks such as creating roles, projects, and associating the user with them is done by the Keystone administrator. The Keystone administration can be done through the Keystone V3 REST API or by using an OpenStack python-based client.

Before you start creating object users, and projects, make sure that Keystone server is configured and the authentication servers are set up properly. Run the following command to see whether Keystone is configured properly: 
mmces service list -a -v

The object users are authorized to the object data and resources by creating and managing roles and ACLs. The roles and ACLs define the actions that can be done by the user on the object resources such as accessing data, managing the projects, creating projects, read, write, and run permissions.