[undertow-dev] Reducing Use of Undertow IdentityManager

[Stuart Douglas]

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.