Page History

Core Authorization Configuration:

Next Step:

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

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

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 lineYou have the option to tailor the non-authorized message to your needs: uncomment this line and insert the desired text:

 // shrine.webclient.unauthorizedMessage = "You currently do not have access to SHRINE. Please contact your institution's SHRINE administrator for more information."
 Enter your message"

(Required) Authorization Logic Configuration:
Authorization has 2 phases:

Phase 1: Collecting "attributes" about the user

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

The authorization system works with any number of individually configured attribute providers which each generate " attributes".  Further, a single authorization provider, also configured here, will determine based on the provided attributes whether the user is authorized or not. Beyond the configuration items 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 pattern is used to integrate with the authorization provider. The system comes with 3 AttributeProviders and 3 Authorizers, ready to be used. If you want to create your own, this requires a bit more legwork than can easily be described here. Contacting us would be the best option.

1. WhiteBlackListAttrProvider

shrine.config.authorizer : {

  unauthorizedUrl = "/shrine-api/shrine-webclient?isAuth=false"

  attributeProviders :
  [   
      
	{...}
     {...}
    {...}
  ],
  authorizer : {
    ...
  }
}

The information gathered by the attribute providers will have the following shape, where each "attribute type" corresponds to an AttributeProvider class. AttributeProvider classes in turn generate a list of attributes, each with one or more values. The authorizer class will use this data to decide whether to authorize the user or not.

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

The system comes with 3 AttributeProviders and 3 Authorizers, ready to be used. If you want to create your own, this requires a bit more legwork than can easily be described here. Contacting us would be the best option.

...

WhiteBlackListAttrProvider:

The WhiteBlackListAttrProvider queries a database's table of whitelisted and blacklisted users. Its typical configuration follows.

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

WhiteBlackList Context.xml Configuration

Note that the table and column names are not configurable. The db table must be named "bw_user" and the columns "ssoId", "whitelisted", and "blacklisted". As configured above, the database name is "blackWhiteTableDB"; but it could be configured to another name. Also, the context.conf file in the tomcat configuration must contain must contain the following:

...

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

    } 

Next Step:

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