bbockelm
commented
6 years ago Restating what you just said, just to make sure I understand. We want:
- An ordered list of access control rules (perhaps sections of a config file).
- An expression (starting simple, such as requiring a particular group member ... but perhaps with future hooks for more complex boolean logic) that specifies the set of identities that match the rule.
- For matching users, an unordered list of allowed scopes.
That seems reasonable to me -- and broadly what I did for the X509-based issuer. Here's the example config file for our CMS demo instance:
{
"rules": [
{"match": "fqan:/cms", "scopes": ["read:/store", "write:/store/user/{username}"]}
]
}So, we have one rule that requires the client to authenticate with a GSI proxy containing a CMS-issued VOMS extension. The server will by default issue a token that allows any CMS file to be read, but only allow the user to write to their home directory (there's some code I'm not highlighting here that maps from DN to username). I'd imagine the group name substitution would be similar.
Note there is some tricky logic (see: https://github.com/bbockelm/x509-scitokens-issuer/blob/master/src/x509_scitokens_issuer/x509_scitokens_issuer.py#L272) around user-specified scopes, since it doesn't necessarily work the same way in SciTokens as in more traditional OAuth2. Basically, a user authorized for scope read:/pathA should be allowed to ask-and-receive the scope read:/pathA/foo/bar, even if read:/pathA/foo/bar isn't explicitly listed in the configuration file.
jbasney
jjg-123
Proposing simple initial policy enforcement in the SciTokens OAuth Provider as follows:
if isMemberof(group, user) # LDAP check then read:/pathA/$GROUP/ write:/pathB/$USER/
where group name and read/write paths can be specified by client configuration.