On 05/03/2016 03:52 PM, Simo Sorce wrote:
John,
It doesn't have to be a failure to authenticate at the IdP,
True, but that's not what the OP stated, the OP statement was:
The plugins would allow various data sources to be used to
allow or reject a SP login process after authentication has
passed, but before the success response is sent back to the SP.
I read that statement as "fail authentication for specific SP's". I do
not read this as authentication succeeds and add an extra attribute for
the SP to process.
it can
simply be a plugin that inserts a single attribute as the result of some
rule checking that will tell whether the user should be allowed in.
mod_auth_mellon, and most other SP software already have rules to check
for attributes and fail authentication if they do not match specific
values.
Yes, and that's exactly what I said:
"It shouldn't be hard to add authorization checks in the SP
where it belongs. It could be as simple as testing one attribute."
IMO it is a valid use case and the implementation can be perfectly
SAML
compatible, even in the spirit (ie failing authorization at the SP
instead of the IdP, even though that is just semantics for the most
Failing authentication and failing authorization are not the same thing.
We already have mechanisms in Ipsilon to add attributes to the
Authentication Assertion and that is what should be used for the simple
cases (when Authorization Assertions are overkill).
Perhaps the question is better framed as:
Is the attribute injection mechanism in Ipsilon sufficiently rich?
Should a plugin interface be developed to allow context specific
attributes to be generated?
That is a different question.
--
John