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 1After 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.
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.
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:
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.
Code Block | ||||
---|---|---|---|---|
| ||||
{ 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 } } |
...
Code Block | ||||
---|---|---|---|---|
| ||||
{ class = net.shrine.authz.providerService.attributes.EndpointAttrProvider name = profiles_faculty_type_and_id url = ".....{userId}....." userIdPlaceHolder="{userId}"{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=\"(.)\"" } ] } |
...
Code Block | ||||
---|---|---|---|---|
| ||||
{ 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 = "(.+)" } ] } |
...
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 } |
...