...
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 #WhiteBlackListConfigurationbelow
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:
Code Block |
---|
|
<Resource name="jdbc/blackWhiteTableDB" auth="Container" type="javax.sql.DataSource"
maxTotal="128" maxIdle="32" maxWaitMillis="10000"
username="shrine" password="demouser" driverClassName="com.mysql.jdbc.Driver"
url="jdbc:mysql://localhost:3306/blackWhiteTableDB?serverTimezone=UTC"
testOnBorrow="true" validationQuery="SELECT 1"/> |
It The WhiteBlackListAttrProvider generates attributes of this shape:
Code Block |
---|
|
wb-list: -> {
isBlack -> (true/false},
isWhite -> (true/false}
}
|
EndpointAttrProvider
The following attribute provider An EndpointAttrProvider fetches data from a remote URL and extracts attributes from that data by using Regexes. As an example is extracts 2 attributes, person_id and faculty_type:
...
Code Block |
---|
|
profiles_faculty_type_and_id -> {
person-id: [...]
faculty_type: [...]
}
|
As an One can re-use EndpointAttrProvider in the same shrine.config.authorizer configuration. For example, the same attribute provider class could be configured as follows
Code Block |
---|
|
{
class = net.shrine.authz.providerService.attributes.EndpointAttrProvider
name = profilesendpoint_everything
url = ".....{userId}....."
userIdPlaceHolder="{userId}"
attributeRegexes : [
{
name = "everything"
regex = "(.+)"
}
]
} |
...
Code Block |
---|
|
profilesendpoint_everything -> {
everything: [...]
} |
Another attribute provider The RequestHeadersAttrProvider extracts values from the HTTP request headers:
Code Block |
---|
|
{
class = net.shrine.authz.providerService.attributes.RequestHeadersAttrProvider
name = headers,
headerNames :
[
AJP_userId
AJP_email
AJP_firstName
AJP_lastName
]
} |
The attributes generated by RequestHeadersAttrProvider as configured above will have this shape:
Code Block |
---|
|
headers -> {
AJP_userId: [...]
AJP_email: [...]
AJP_firstName: [...]
AJP_lastName: [...]
}
|
HmsAuthorizer
The authorization provider, for example, HmsAuthorizer, which makes use of the attributes generated by a WhiteBlackListAttrProvider and a REST call to the HMS profiles servicethe attribute providers.
Code Block |
---|
|
authorizer : {
name : net.shrine.authz.providerService.authorize.HmsAuthorizer
} |
...
A more flexible authorization provider could be the followingRegexAuthorizer. It concatenates all the received attributes and values, and then applies any number of Regexes to it. Authorization is granted if all regexes find a match. A "!" before a Regex means that there should not be a match.
Code Block |
---|
|
//////////////////////////////////////////////////////////// You are authorizied if and only if:
// example of an alternate authorizer: RegexAuthorizer //
//////////////////////////////////////////////////////////// -- you are not black-listed --and-- you are either white-listed or you have a certain faculty type.
// But in any case, the string 'fp77' better not appear anywhere in your attributes
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)"
]
} |
...