There is another "Act as" for grouper, which is audited. This enhancement is for Grouper messaging to web services and is not audited (more of a backdoor).
Send the act as
To get this to work, an HTTP header is sent with the request. You need to send the source ID. And you need to send the id or identifier. Note, this is a layer on top of the normal actAs and does not conflict, both can be used. Note these header values should be BASE64 encoded with UTF-8.
X-Grouper-actAsSourceId: base64(sourceId) X-Grouper-actAsSubjectId: base64(subjectId) -or- X-Grouper-actAsSubjectIdentifier: base64(subjectIdentifier)
e.g. for jdbc and test.subject.0
X-Grouper-actAsSourceId: amRiYw== X-Grouper-actAsSubjectId: dGVzdC5zdWJqZWN0LjA=
Grouper client options
--grouperActAsSubjectId=subjId --grouperActAsSubjectIdentifier=subjIdent --grouperActAsSubjectSource=sourceId
Configure the WS to accept a grouper act as
in grouper-ws.properties
# similar syntax as ws.act.as.group but for the grouper actas (e.g. for grouper messaging to WS bridge) # Web service users who are in the following group can use the actAs field to act as someone else # You can put multiple groups separated by commas. e.g. a:b:c, e:f:g # You can put a single entry as the group the calling user has to be in, and the grouper the actAs has to be in # separated by 4 colons # e.g. if the configured values is: a:b:c, e:f:d :::: r:e:w, x:e:w # then if the calling user is in a:b:c or x:e:w, then the actAs can be anyone # if not, then if the calling user is in e:f:d, then the actAs must be in r:e:w. If multiple rules, then # if one passes, then it is a success, if they all fail, then fail. ws.grouper.act.as.group =
1 Comment
Carey Black (osu.edu)
I don't think this note is very clear. " Note, this is a layer on top of the normal actAs and does not conflict, both can be used. "
Q) Can the new one be used without using the older method? ( a substitute way to make the same request?)
Q) Or can the new way only be used if the old way is also being used?
Q) Also, the permissions model is a bit hard to follow. Maybe an example would be easier / clearer?
My guess is that:
The Web service call is authenticated as user "WebServiceUser".
Then "WebServiceUser" needs to be able to use the "normal/older actAs" to become the second user ("Bob") that is included in the "old" act as value from inside of the the web service message.
Then this new "actAs" would require "Bob" to be allowed to act as the user ("Sally") that is indicated in the headers of the WebService call?
Or (And this would make less sense to me... but maybe...)
The Web service call is authenticated as user "WebServiceUser".
Then "WebServiceUser" needs to be able to use the "normal actAs" to become the second user ("Bob") that is included in the "old" act as indicated inside of the the web service message.
Then this new "actAs" would also require "WebServiceUser" to be allowed to act as the user ("Sally") that is indicated in the headers of the WebService call?