5:58 p.m.
Bill Burke wrote:
On 5/31/2013 1:46 AM, Stuart Douglas wrote:
>
>
> Bill Burke wrote:
>> I don't think these undertow SPIs need be that complex. JBossWeb
>> security valves delegate to a Realm. A realm which handles
>> authentication and the setting of role mapppings. This has a lot of
>> limitations and is not very flexible.
>>
>> Instead, allow the security valve to set the subject/principal and
>> provide a callback for isUserInRole(). A good example is the JAX-RS
>> SecurityContext.
>>
>> interface SecurityContext {
>> public Principal getUserPrincipal();
>> public boolean isUserInRole(String role);
>> }
>>
>
> This is basically what Darran is proposing, after his changes the
> Account interface will look the same as above.
>
> I am not 100% convinced that this is a good idea though.
I hope you mean that you think the simple "SecurityContext" SPI is a
good idea, but not having a more general IDM SPI *in addition* is the
bad idea.
Yes, sorry I should have been more clear. I am for the minimum security
context SPI, just was not sure about the identity manager changes.
I have been thinking about this all weekend, and I am still not really
sure what the best way to handle this is. For now I think I will merge
Darran's PR with the cut down IDM and see how that works out. I think
that once we have a few custom authentication mechanisms it will be a
lot clearer if a more full featured IDM interface would help, and if so
what form it should take.
Stuart
At least for my stuff, my server applications don't even an IDM SPI as
they obtain information from the request. An IDM SPI just gets in the
way. And my Identity Service may not even be able to use an IDM SPI at
the normal integration points because of provisioning issues and the
fact that we want customizable login screens per security domain.
> I don't mind the idea of having a general purpose IDM module though.
> Potentially you could have this small general purpose one just provide
> the basic methods, and Picketlink provide a more full featured one that
> extends it. This means you would not need any sort of IDM bridge to make
> Undertow work with Picketlink, without them depending on each other.
>
I think this general IDM SPI should live in Picketlink as IMO, this is
part of their charter. Of course the necessary interfaces should be
isolated in their own module. Just as DML put the hammer down on
requiring JBoss Logging and XNIO, you should be consistent with the
other core SPIs. If it is a matter of Picketlink underdelivering, then
thats another different conversation that needs to happen.
Its your baby, your decision, but I at least want the small tiny
"SecurityContext" SPI I've been talking about.