Page History

...

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>"

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." 

...

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

(Required) Authorization Logic Configuration:

Authorization has 2 phases:

Phase 1: Collecting "attributes" about the user

...

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

After the configuration items indicated above, the config file has the following overall structure. The following configuration should also reside in the shrine.conf, after the above config. (Phase 1) The following , shrine.conf, also needs a configuration called 'shrine.config.authorizer', of the following form: 

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 Authorizers (only one of which must appear in the configuration), ready to be used. If you want to create your own providers, this requires a bit more legwork than can easily be described here. Contacting us would be the best option.

...

Code Block
language yml theme Midnight
// Configuration for Phase 1 (attribute providers) and Phase 2 (one authorizer) // shrine.config.authorizer : { unauthorizedUrlattributeProviders : = "/shrine-api/shrine-webclient?isAuth=false" attributeProviders :// this example uses three attribute providers -- there must be a non-empty list [       {...} // configuration for one available attribute provider   {...} // configuration for one available attribute provider    {...} // configuration for one available attribute provider   ],  authorizer : { // exactly one authorization provider must be configured ... // configuration for one available authorization provider } }

The

...

attribute providers will

...

assemble attributes in a data structure with the following form: Each "attribute type" corresponds to an AttributeProvider class.

...

Each AttributeProvider class generates a list of "attributes",

...

and each of the attributes has a list of values. The authorizer class will use this data to decide whether to authorize the user or not.

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

...