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:
Code 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:
Code Block | ||||
---|---|---|---|---|
| ||||
// 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.
...
Code Block | ||||
---|---|---|---|---|
| ||||
// 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 } } |
...
Code Block | ||||
---|---|---|---|---|
| ||||
// 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:
...
Code Block | ||||
---|---|---|---|---|
| ||||
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.
Code Block | ||||
---|---|---|---|---|
| ||||
// 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 } |
...