Page History

Core Authorization Configuration:

If you want to use authorization, you must first add the following configuration to shrine.conf, after the existing shrine block:

shrine {

...

}
... 
shrine.config.authorizer.requireAuthorization = "true"
shrine.webclient.ssoLogoutUrl = "https://<your hostname>/shrine-api/authorizer/logout"
shrine.config.authorizer.shibLogoutUrl = "https://<your hostname>/Shibboleth.sso/Logout?return=<return URL provided by your idP>"
// shrine.webclient.unauthorizedMessage = "Enter your message"

Unauthorized Message:

The default unauthorized message is as follows and currently baked into the code: "You currently do not have access to SHRINE. Please contact your institution's SHRINE administrator for more information." 

(Optional) The unauthorized message can be tailored to your needs in shrine.conf by uncommenting and updating the following linemessage:

 // shrine.webclient.unauthorizedMessage = "Enter your message"

...

Authorization has 2 phases:

Phase 1: Collecting "attributes" about the user. Note: the user is identified by the REMOTE_USER / userId header passed by the SP – See section A.3

Phase 2: Making an authorization decision based on the attributes collected in Phase 1

The authorization system works with any number of individually configured (Phase 1) attribute providers, each of which can generate attributes.  Further, a single (Phase 2) authorization provider, must also configured here, be configured. The authorization provider will determine, based on the provided collected attributes, whether the user is authorized or not.

NOTE: After the configuration items indicated above

...

in the

...

shrine.conf config file, we also

...

need to add a configuration block called 'shrine.config.authorizer'

...

.

The following configuration pattern is used to integrate attribute providers with the authorization provider. The system currently comes with 3 available AttributeProviders and 3 available

...

Authorization Providers. However, the system can be configured with any number of AttributeProviders but only one of

...

the AuthorizationProvider should be configured and be used.

// Configuration for Phase 1 (attribute providers) and Phase 2 (one authorizer)
//
shrine.config.authorizer : {

  attributeProviders :  // this example uses three attribute providers -- there must be a non-empty list 
  [       
	{...} // configuration for an available attribute provider
    {...} // configuration for an available attribute provider
    {...} // configuration for an available attribute provider
   ],
  authorizer : {        // exactly one authorization provider must be configured
    ...   // configuration for an available authorization provider
  }
}

...

// 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, ...],
   *     ...
   *   },
   *   ...
   * }

...

Attribute Providers Configuration:

WhiteBlackListAttrProvider:

The WhiteBlackListAttrProvider queries a database's table of whitelisted and blacklisted users. Its typical configuration follows. It finds the user by looking for the REMOTE_USER / userId passed by the SP.

    {
      class = net.shrine.authz.providerService.attributes.WhiteBlackListAttrProvider
      name = wb-list,
      // DB config here should correspond to tomcat's Resource in its context.xml, see below
      database: {
        dataSourceFrom = "JNDI"
        jndiDataSourceName = "java:comp/env/jdbc/blackWhiteTableDB"
        timeout = "30 seconds"
        createTablesOnStart = false
      }
    }

...

    {
      class = net.shrine.authz.providerService.attributes.EndpointAttrProvider
      name = profiles_faculty_type_and_id
      url = ".....{userId}....."  
      userIdPlaceHolder="{userId}" // the REMOTE_USER / userId will get substituted into the Url for this placeholder
      attributeRegexes : [
        {
          name = "person-id"
          regex = "PersonID=\"([0-9]+)\""
        }
        {
          name = "faculty_type"
          regex = "<Affiliation Primary=\"true\">.*?FacultyTypeSort=\"(.)\""
        }
      ]
    }

...

    {
      class = net.shrine.authz.providerService.attributes.EndpointAttrProvider
      name = endpoint_everything
      url = ".....{userId}....."
      userIdPlaceHolder="{userId}"
      attributeRegexes // the REMOTE_USER / userId will get substituted into the Url for this placeholder 
      attributeRegexes : [
        {
          name = "everything"
          regex = "(.+)"
        }
      ]
    }

...

headers -> {    
		AJP_userId: [...]
        AJP_email: [...]
        AJP_firstName: [...]
        AJP_lastName: [...] 
}
  

Authorization Providers Configuration:

HmsAuthorizer

The authorization provider, for example, HmsAuthorizer, makes use of the attributes generated by the attribute providers.  Per the requirements for HMS, HmsAuthorizer checks a 'Profiles' endpoint.

  // You are authorizied if and only if:
  //         You are not black-listed 
  // --and-- you are either white-listed or your faculty type is from 0 to 4 inclusive 

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

...

  // You Given the below regexTerms, you are authorizied if and only if:
  // -- you         You are not black-listed 
  // --and-- you are either white-listed or your faculty type is from 0 to 4 inclusive.
  // But in any case,--and-- the string 'fp77' betterdoes not appear anywhere in your attributes

  authorizer : {
      name : net.shrine.authz.providerService.examples.RegexAuthorizer
      regexTerms :
          [
             "wb-list.isBlack.false"
             "(wb-list.isWhite.true)|(faculty_type_and_id.faculty_type.[0-4])"
             "!(fp77)"
          ]

    }

BWAuthorizer

With BWAuthorizer, authorization is granted if the user is white-listed and NOT black-listed.

  // You are authorizied if and only if you are white-listed but NOT black-listed 
  
  authorizer : {
      name : net.shrine.authz.providerService.authorize.BWAuthorizer
    }

Next Step:

SHRINE 4.1.0 Appendix A.9 - Starting and Stopping the Software

...