The below image provides an explanation on how SAM functions for the above use case.

Step 1: Initial Login

User gvetticaden authenticates himself to the organization AD/KDC by doing a kinit. Typically in an organization, the ticket is granted when the user logs into the corporate LAN.

Principal/Keytab Used to Connct: gvetticaden

Step 2: SAM Grants Access Based on Roles and Permissions

SAM looks up the roles for gvetticaden. Based on the permissions associated with the roles, SAM gives gvetticaden access to specific features.

Step 3a: Build and Deploy a Streaming Application

User gvetticaden builds the streaming analytics application and deploys it. The application includes the following capabilities:

Step 3b: SAM Communicates with Storm

SAM communicates with Storm Streaming Engine to deploy the stream application using the streamline principal/keytab. SAM is functioning as a client submitting a job to Secure Storm. The internal streamline user will impersonate gvetticaden when it talks to Storm. Hence ACLs within Ranger for Storm can be configured for gvetticaden, the person deploying the streaming application.

Principal/Keytab Used to Connect: The streamline principal/keytab is used to connect, and user gvetticaden is impersonated.

Step 4: Communication with Secured Big Data Services

When SAM deploys the application, it passes the application principal and keytab to Nimbus. Nimbus uses this principal to authenticate to big data services that support tokens. The principal impersonates gvetticaden. The result is that all Ranger ACLs for HBase, Hive, and HDFS are configured for gvetticadne, the user deploying the streaming application.

Step 5: Communication with Secured Big Data Services that do not Support Delegation Tokens

If the application uses a Kafka Source or Sink, then the application uses the principal and keytab configured under the Kafka component security settings.

Principal/Keytab Used to Connect:: The principal/keytab configured in Kafka are used to connect.