Well, that should have been prevented. If you don't have a SciToken and
you expected one with, say, unix then you shouldn't forward the request.
If you don't have it but it is GSI (or some other strong authentication
mechanism you trust) then you can forward it.
From my understanding, based on what I read, is that SciToken is self
describing. That is, if you have one then it encodes all possible
priveleges for the resource it describes and you neither want to
further restrict them nor expand them using some other authorization
scheme. Doing so makes auditing next to impossible.
Adding authentication protocol rules to the basic authorization database
adds sufficient complexity, I think, that people would have a hard time to
properly specify the rules; defeating the whole purpose here (I could be
convinced otherwise, I suppose). The system expects, whatever
authentication scheme is used, it properly fills out the SecEntity
structure. That should be sufficient for what is used here. Unix nor any
other untrusted authentiation does not fill in fields on which decisions
are made. Hence, there is no information to grant privileges.
Andy
On Mon, 4 May 2020, Brian P Bockelman wrote:
>> Yes. If you have a set of authorization plugins that are authentication type sensitive, you can stack them
>
> This isn't exactly what I was getting at. Within the default authorization module, is there any way to setup rules that *only* match authentication information coming from a specific plugin?
>
> Let's say I do a "SciTokens" plugin stacked with the default one and then a client performs Unix authentication without a token. How do I stop it from matching a rule like:
>
> ```
> u bbockelm /store a
> ```
>
> ? I only trust the user information filled in by the GSI authentication, not the Unix auth.
>
> --
> You are receiving this because you were mentioned.
> Reply to this email directly or view it on GitHub:
> https://github.com/xrootd/xrootd/issues/1188#issuecomment-623798192
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or unsubscribe.
[
{
"@context": "http://schema.org",
"@type": "EmailMessage",
"potentialAction": {
"@type": "ViewAction",
"target": "https://github.com/xrootd/xrootd/issues/1188#issuecomment-623816144",
"url": "https://github.com/xrootd/xrootd/issues/1188#issuecomment-623816144",
"name": "View Issue"
},
"description": "View this Issue on GitHub",
"publisher": {
"@type": "Organization",
"name": "GitHub",
"url": "https://github.com"
}
}
]
Use REPLY-ALL to reply to list
To unsubscribe from the XROOTD-DEV list, click the following link:
https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=XROOTD-DEV&A=1
