Managing Impersonation

Example: Access Control and Impersonation

As an example of impersonation, consider user Bob and a generic Service X:

1. Bob launches a client for the service and may or may not provide credentials.
2. Service X authenticates Bob and establishes a connection for him to use.
3. Bob issues a command to the service that will produce a query.
4. The service uses any user's servicewithimpersonation ticket or the mapr superuser to authenticate with the datastore - MapR-FS/MapR-DB.
5. The datastore authenticates the user with the impersonation ticket or the mapr superuser - the service can now proceed.
6. The service sends the datastore a query, as user Bob.
7. The datastore checks permissions for Bob on the assets that the query will access.
8. If Bob has permissions, the datastore returns the query results to the service, which relays the results to the client, and the query succeeds.
9. If Bob does not have permissions, the datastore sends an access error to the service, which relays the error to the client, and the query fails.

When you use impersonation in MapR:

• The datastore permissions are authoritative.
• The process has end-to-end security.
• Users can do nothing more and nothing less than what they are authorized to do.
• This control is independent of remote authentication and security mechanisms that control user access to application features.
• Any permissions set up within applications, or within the UNIX file system permissions on servers where MapR components reside, have no effect on user access to MapR resources.
• The mapr superuser is allowed to impersonate any MapR user in any group, connecting from any host. Other users with impersonation capability can impersonate any MapR user in any group, except the mapr superuser.

Using Impersonation without Security

Although it is possible to enable impersonation in a non-secure MapR installation, MapR strongly recommends against doing this. The implementation rules are different, and setting up the MapR environment with impersonation operating under those rules makes it very difficult to enable security at a later date. Disabling security in a secure MapR installation is easy, if the need arises.

If you choose to implement impersonation in a non-secure MapR cluster, see Configuring Impersonation when Cluster Security is not Enabled.

Using Impersonation with Security

In general, this documentation assumes that security is enabled in your MapR installation. See Enabling Wire-level Security.

You can use the maprlogin utility to generate a servicewithimpersonation ticket that can be used to access a secure cluster impersonating another user. That is, the servicewithimpersonation ticket provides the user the ability to impersonate other users (except the mapr user) in addition to the ability to access a secure cluster. The servicewithimpersonation ticket can only be generated by a user with full control on a cluster's Access Control List (ACL).

If you are setting up user impersonation in a secure cluster, you need to generation an impersonation ticket. See the Generating and Printing Service with Impersonation Ticket section in the maprlogin Command Examples topic and Generating a Service with Impersonation Ticket for information on generating an impersonation ticket.