Page History

...

// Structure of attribute-collection generated in Phase 1
* {
   *   attribute type 1 -> {
   *     attribute 1 -> [value 1, value 2, ...],
   *     attribute 2 -> [value 1, value 2, ...],
   *     ...
   *   },
   *   attribute type 2 -> {
   *     attribute 1 -> [value 1, value 2, ...],
   *     attribute 2 -> [value 1, value 2, ...],
   *     ...
   *   },
   *   ...
   * }

Specific Provider Configurations

WhiteBlackListAttrProvider:

The WhiteBlackListAttrProvider queries a database's table of whitelisted and blacklisted users. Its typical configuration follows.

...

    wb-list: -> {
              isBlack -> (true/false},
              isWhite -> (true/false}
                }

EndpointAttrProvider

The following attribute provider fetches data from a remote URL and extracts attributes from that data by using Regexes. As an example is extracts 2 attributes, person_id and faculty_type:

...

profiles_everything -> {
  everything: [...]
}

RequestHeadersAttrProvider

Another attribute provider extracts values from the HTTP request headers:

    {
      class = net.shrine.authz.providerService.attributes.RequestHeadersAttrProvider
      name = headers,
      headerNames :
        [
           AJP_userId
           AJP_email
           AJP_firstName
           AJP_lastName
        ]
      }

HmsAuthorizer

The authorization provider, Finally the authorizer is named and configured. In the present case, the HmsAuthorizer, which makes use of the attributes generated by a WhiteBlackListAttrProvider and a REST call to the HMS profiles service. 

  authorizer : {
    name : net.shrine.authz.providerService.authorize.HmsAuthorizer
  }

RegexAuthorizer

A more flexible authorizer authorization provider could be the following. It concatenates all the received attributes and values, and then applies any number of Regexes to it. Authorization is granted if all regexes find a match. A "!" before a Regex means that there should not be a match.

...