Introduction 

After adding support for Authorization in CDAP we are are enforcing authorization for operation on different cdap entities through AuthorizationEnforcer in the below way:

public synchronized void create(final NamespaceMeta metadata) throws Exception {
  // Namespace can be created. Check if the user is authorized now.
  Principal principal = authenticationContext.getPrincipal();
  authorizationEnforcer.enforce(instanceId, principal, Action.ADMIN);
  ....
  ...
}

The AuthorizationEnforcer is also used to create filters for entities which is accessible to an user. This is typically used in list operations:

public List<NamespaceMeta> list() throws Exception {
  List<NamespaceMeta> namespaces = nsStore.list();
  Principal principal = authenticationContext.getPrincipal();
  final Predicate<EntityId> filter = authorizationEnforcer.createFilter(principal);
  return Lists.newArrayList(
    Iterables.filter(namespaces, new com.google.common.base.Predicate<NamespaceMeta>() {
      @Override
      public boolean apply(NamespaceMeta namespaceMeta) {
        return filter.apply(namespaceMeta.getNamespaceId());
      }
    })
  );
}

The above process is very cumbersome because of the following reason:

1. A developer will first need to make sure he has all the needed module injected to use AuthorizationEnforcer and AuthenticationContext. 
2. Create and initialize an instance of AuthorizationEnforcer and AuthenticationContext
3. Use them at various place in their code to enforce Authorization.

Moreover, we require authorization enforcement all over cdap code base which requires the above to be done at a lot of places.

Also, in coming releases we also want to support enabling/disabling operation depending on user privileges. For example if an user does not have "ADMIN" privilege on a program the "START" button in the UI should be disabled for that user. Similar feature is needed in CLI too where the auto complete should only show options for which the user have privileges. Although, this requirement is out of score for 4.0 we will like to design the Authorization Enforcement mechanism to support this in near future.

The above calls for some redesign in the authorization enforcement to simplify and standardize authorization enforcement across CDAP code base and also provide a good base for further UI enhancement. The design in following section present an approach to solve the above issues.

Goals

1. Simplify and standardize the process of authorization enforcement in CDAP.
2. Support Authorization all across CDAP (Logs, Metrics, Stream Views, Metadata, Preferences, Kafka, Explore)

3. Enable/Disable operations on the fly for the logged in user (Out of scope for 4.0)

User Stories 

1. As a CDAP developer, I would like to easily enforce authorization for a code block with minimal code in a standard way.
2. As a CDAP security admin, I will like to enforce authorization on all entities in CDAP.
3. As a CDAP security admin, I will like users to access/view only the operation for which they have appropriate privileges. (Out of scope of 4.0)

Scenarios

• Scenario #1

  Bhooshan is a ninja CDAP developer who is working on a cool new feature, adding lots of new publicly exposed APIs and he want  support authorization enforcement for his new feature. He looks around in CDAP code base and finds out that he will need to get some classes through injector and put conditional checks at various places in his new code. He feels overwhelmed by all this new changes and will like to have a simplistic and standard to add authorization.
  
  

• Scenario #2

  Derek is an IT Operations Extraordinaire at a corporation that uses CDAP. He just upgraded CDAP to use the new authorization features. He granted all the appropriate privileges to different users of CDAP in his corporation and left for the day. When he comes back to the office next day he sees a new ticket assigned to him created by Mr. Little Fingers who is angry because Mr. Tim can see all the logs and metrics which his CDAP programs are generating. Derek is furious and after some digging he identifies that not all entities in CDAP supports authorization and he will like to enforce authorization on all entities in CDAP. 
  
  

• Scenario #3 (Out of scope for 4.0)

  Derek (IT Operations) has been appreciating the authorization feature of CDAP as it has restricted unintentional usage of CDAP entities among the users in his coporation. But he does not like that users can see the UI button to run a CDAP program even though the user does not have privileges for it. This creates an unnecessary confusion among users. He thinks that it will be helpful if an user can only see operations for which he has privileges. 

Design

In our current code base we do authorization enforcement where the entity id on which enforcement is being done is one of the following: 

StreamQueueReader.dequeue

ArtifactRepository.deleteArtifactProperties

ArtifactRepository.addArtifact

To represent all the above possibilities we propose the following annotation.

/**
 * Annotation for a method that needs Authorization
 */
@Retention(RetentionPolicy.RUNTIME)
@Target(ElementType.METHOD)
public @interface AuthEnforce {

  // The name of the variable which is the entity id on which or on whose parent authorization needs to be enforced.
  // This variable will be first looked in method parameters, if one is not found it will be looked into class member
  // variables
  String[] entity();

  // Class name of one of the CDAP entities on which enforcement will be done
  Class enforceOn();

  // Array of Action to be checked during enforcement
  Action[] privileges();
}

entity: Specifies the entity on which authorization will be enforced. It can either be a variable name of the EntityId or an array of Strings from which the entity id can be constructed. This variable will be first looked up in the method parameter and if not found it will be looked up in the class member variable.

enforeOn: Specifies the entityId on which authorization enforcement will be done. It is possible to pass ProgramId in "entity" and enforce authorization on NamespaceId by passing NamespaceId.class here. This allows developers to enforce on parents of an entity. In the case of "entity" being an array of String enforceOn specifies the entityId which will be created.

privileges: The privileges to check for during authorization enforcement on this entity. This is an array of Actions to allow enforcing multiple checks.

Any method needing authorization enforcement can be annotated with the above annotation. Below are few example:

@AuthEnforce(entity = "artifactId", enforceOn = ArtifactId.class, privileges = {Action.ADMIN})
public void writeArtifactProperties(Id.Artifact artifactId, final Map<String, String> properties) throws Exception {
  artifactStore.updateArtifactProperties(artifactId, new Function<Map<String, String>, Map<String, String>>() {
	...
  });
}

@GET
@Path("/{stream}/events")
@AuthEnforce(entity = {"namespaceId", "stream"}, enforceOn = StreamId.class, privileges = {Action.READ})
public void fetch(HttpRequest request, final HttpResponder responder,
                  @PathParam("namespace-id") String namespaceId,
                  @PathParam("stream") String stream,
                  @QueryParam("start") @DefaultValue("0") String start,
                  @QueryParam("end") @DefaultValue("9223372036854775807") String end,
                  @QueryParam("limit") @DefaultValue("2147483647") final int limitEvents) throws Exception {

The MainClassLoader which extends an InterceptableClassLoader and is also a FilterClassLoader will be responsible for intercepting and filtering all the classes which need class rewrite by looking for the presence of AuthEnforce annotation. During the class rewrite phase all methods which have AuthEnforce annotation will be rewritten where the first line of the method will be authorization enforcement something like below:

public void writeArtifactProperties(Id.Artifact artifactId, final Map<String, String> properties) throws Exception {
  authorizationEnforcer.enforce(artifactId.toEntityId(), authenticationContext.getPrincipal(), Action.ADMIN);
  artifactStore.updateArtifactProperties(artifactId, new Function<Map<String, String>, Map<String, String>>() {
	...
  });
}

API changes

New Programmatic APIs

AuthEnforce annotation as mentioned above.

Deprecated Programmatic APIs

None

New REST APIs

None

Deprecated REST API

None

CLI Impact or Changes

None

UI Impact or Changes

None

Security Impact 

We will replace authorization enforcement all across CDAP with the new AuthEnforce annotation. We expect to write a good Authorization Integration test suite which we can depend on to make sure nothing getting affected by these changes. 

Impact on Infrastructure Outages 

None

Test Scenarios

Releases

Release 4.0.0

• Goal 1: Simplify and standardize the process of authorization enforcement in CDAP.
• Goal 2: Support Authorization all across CDAP (Logs, Metrics, Stream Views, Metadata, Preferences, Kafka, Explore)

Release 4.1.0

• Goal 3: As a CDAP security admin, I will like users to access/view only the operation for which they have appropriate privileges. (Out of scope of 4.0)

Related Work

• Error rendering macro 'jira' : Unable to locate Jira server for this macro. It may be due to Application Link configuration.
  
  
• Unable to locate Jira server for this macro. It may be due to Application Link configuration.
• Standardize authorization enforcement across CDAP so we can use AuthEnforce annotation. For example there are some handlers which does Authorization enforcement. Ideally, we will want them to happen in the admins.  

Future work

Enabling/Disabling action in UI and CLI

The future work involves taking advantage of authorization annotation to enable/disable actions in UI and CLI for an user on the fly. Below we discuss an initial design to showcase that this is possible with authorization annotation.

We will add an unique name called actionId to every annotation. This will serve as a map between UI and the backend so that for every action in UI we will know what privileges needs to be enforced and on which entity.

@AuthEnforce(

     entity("pid": EntityId)

     enforceOn(ApplicationId.class)

     privileges({ADMIN, EXECUTE})
 
     actionId("uniqueActionName")
)

PrivilegeInspector: When CDAP  Master starts privilege inspector can inspect all the authorization annotation to create a map of  privileges needed for a given action.

Querying Privileges: Once the action to required privilege map is build by the PrivilegeInspector this can be served to the  UI. We will introduce new endpoints which which will map every page in UI (like ns page, app page etc) which can be used to construct entityId on which authorization needs to be enforced and the UI will also pass set of unique action names for which privileges needs to be checked.

For example let's say a user is on a program page  (/ns/appid/program/checkactions)

/programs end point can be hit with  /program {ns, appid} {set of actions: start, stop}

Now the handler can use the map created by the privilegeInspector to know what privileges are needed for the requested action.