There are 2 ways to identify yourself to MapR, as yourself via MapR Authentication, or by pretending to be someone else, via MapR Impersonation.
MapR Authentication
$ maprlogin password -user blim
[Password for user 'blim' at cluster 'maprcluster': ]
You login with the maprlogin facility and provide your username and password. Once you've successfully logged in, a user ticket is created by maprlogin and saved by default in /tmp/. You'll use this ticket to identify yourself in all future MapR operations.
The problem with this scheme is that you have to provide credentials. This assumes that every user has a user/password combination.
MapR Impersonation
Before we get into impersonation we need to understand service tickets.
MapR service tickets is a way for services (e.g. xcalar, hive, hue, etc) to identify themselves to MapR without having to enter a user/password.
For example, suppose I'm admin, and I just installed xcalar. I would like to grant xcalar access to the MapR cluster. I can do so by generating a service ticket and handing the ticket to xcalar.
To do so,
1) First login as admin
$ maprlogin password -user admin
[Password for user 'admin' at cluster 'maprcluster': ]
2) Now, logged in as admin, generate the service ticket
$ maprlogin generateticket -type service -user xcalar -duration 30:0:0 -out ./xcalar.ticket
MapR credentials of user 'xcalar' for cluster 'maprcluster' are written to './xcalar.ticket'
3) Now I'll copy the xcalar.ticket to a xcalar node
$ scp xcalar.ticket xcalar@xcalar-node:~
4) Now with the xcalar ticket, xcalar will be able to access mapr directly
$ MAPR_TICKETFILE_LOCATION=pwd/xcalar.ticket xcMapRClient ls --path /user/
[{"mLastMod": 1502223460, "mKind": "D", "mName": "/user/admin", "mSize": 2, "mReplication": 3, "mGroup": "5000", "mBlockSize": 268435456, "mLastAccess": 1501625753, "mOwner": "5000", "mPermissions": 493}, {"mLastMod": 1513131691, "mKind": "D", "mName": "/user/dwtestuser", "mSize": 1, "mReplication": 3, "mGroup": "blim", "mBlockSize": 268435456, "mLastAccess": 1513130226, "mOwner": "blim", "mPermissions": 493}, {"mLastMod": 1501626309, "mKind": "D", "mName": "/user/hive", "mSize": 1, "mReplication": 3, "mGroup": "5000", "mBlockSize": 268435456, "mLastAccess": 1501626309, "mOwner": "5000", "mPermissions": 493}, {"mLastMod": 1501627805, "mKind": "D", "mName": "/user/root", "mSize": 3, "mReplication": 3, "mGroup": "root", "mBlockSize": 268435456, "mLastAccess": 1501626913, "mOwner": "root", "mPermissions": 493}]
In this way, when you use xcalar, you'll be able to access MapR with Xcalar without having to enter your login credentials to MapR.
The problem now though, is that no matter who's logged onto xcalar, when xcalar is accessing MapR, it's doing so as itself. This means we have lost
1) Auditability. We don't actually know who xcalar is accessing MapR on behalf of and
2) Permissions. Since xcalar is accessing MapR as itself no matter who is behind the wheel, there is no way to enforce that Bob wouldn't be able to access John's file.
Here comes impersonation. Essentially, we're telling xcalar to access MapR on behalf of a user. Say I'm jsmith and I'm using xcalar. Now behind the scenes, xcalar will invoke the following command:
MAPR_TICKETFILE_LOCATION=pwd/xcalar.ticket xcMapRClient --user jsmith ls --path /user/
The xcalar service is still using the xcalar.ticket to authenticate itself against the MapR cluster. But it also lets the MapR cluster know that it's doing the bidding of jsmith.
The catch is, if we use a regular service ticket, MapR will fail this request because MapR doesn't know that the xcalar service is trusted enough that it can pretend to be someone else.
Thus, an admin will need to generate a special kind of ticket for xcalar to allow xcalar to act on behalf of users, i.e. a service with impersonation ticket.
To do so,
$ maprlogin generateticket -type servicewithimpersonation -user xcalar -duration 30:0:0 -out ./xcalar-with-impersonation.ticket
Now, with this ticket, the following command will succeed:
MAPR_TICKETFILE_LOCATION=pwd/xcalar.ticket xcMapRClient --user jsmith ls --path /user/
You can tell the difference between the 2 tickets as follows:
$ maprlogin print -ticketfile impersonation.ticket
Opening keyfile impersonation.ticket
maprcluster: user = dwtestuser, created = 'Tue Dec 12 18:46:19 PST 2017', expires = 'Thu Jan 11 18:46:19 PST 2018', RenewalTill = 'Thu Jan 11 18:46:19 PST 2018', uid = 5002, gids = 5003, CanImpersonate = true
$ maprlogin print -ticketfile service.ticket
Opening keyfile service.ticket
maprcluster: user = dwtestuser, created = 'Tue Dec 12 21:43:27 PST 2017', expires = 'Thu Jan 11 21:43:27 PST 2018', RenewalTill = 'Thu Jan 11 21:43:27 PST 2018', uid = 5002, gids = 5003, CanImpersonate = false
Notice the "CanImpersonate" field.
So... What does this mean for Xcalar's MapR connectors?
This means that we'll actually provide 2 ways of connecting to MapR, via MapR Authentication and via MapR impersonation. This is where Data Targets really shine.
For the MapR Authentication Data Target, you'll need to supply the following arguments:
1) Username
2) Password
For the MaprR Impersonation Data Target, you'll need to supply the following arguments:
1) Path to service with impersonation ticket
The user it actually impersonates is the user currently logged into Xcalar Design. This is still subject to change.
