You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When the mapping is successful but the scope authz failed the chained authz plugin is called without the mapping info. I am referring to the following line:
How is the chained authz plugin expected to extract the mapping information from a token that it might not be able to decode? It would help if the new username that is now populating the Entity->eaAPI[request.name] should also be set for the new_secentity that is passed to the OnMissing call.
The text was updated successfully, but these errors were encountered:
Wouldn't this largely negate the whole point of having restrictions in the token?
That is, if we populate the username and you got access to your home directory -- despite having a scopes that do not allow access to the home directory -- it would be a very surprising outcome!
I think this discussion has essentially stalled. There has been a lot of evolvement of the token handling as well as definition. So, likely this is no longer relevant.Please feel free to start a new discussion.
When the mapping is successful but the scope authz failed the chained authz plugin is called without the mapping info. I am referring to the following line:
https://github.com/xrootd/xrootd/blob/master/src/XrdSciTokens/XrdSciTokensAccess.cc#L408
How is the chained authz plugin expected to extract the mapping information from a token that it might not be able to decode? It would help if the new
username
that is now populating theEntity->eaAPI[request.name]
should also be set for thenew_secentity
that is passed to theOnMissing
call.The text was updated successfully, but these errors were encountered: