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"

...

(Optional) The unauthorized message can be tailored to your needs in shrine.conf by uncommenting and updating the 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

After the configuration items indicated above, the config file, shrine.conf, also needs a configuration called 'shrine.config.authorizer'.

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 be configured. The authorization provider will determine, based on the collected attributes, whether the user is authorized or not. 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 (only one of which must appear in the configuration), ready to 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:

...

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, as well as white-and-black lists.

  // 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
  }

...