[undertow-dev] Reducing Use of Undertow IdentityManager

Stuart Douglas sdouglas at redhat.com
Fri May 31 01:46:52 EDT 2013



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. This means that 
most custom authentication mechanisms will be relying on having a 
specific external IDM implementation, so it won't really be possible to 
write a custom pure Undertow authentication mechanism, it will always be 
Undertow + Picketlink, or Undertow + Wildfly, and if you want a truly 
standalone auth mechanism you will basically have to create your own IDM 
interface to allow the identity store to plug in.

I am worried that if we don't have a standard Undertow IDM interface 
everyone is just going to invent their own as needed, and it will turn 
into a bit of a mess.

We also need to think about the embedded case, if you are using Undertow 
as a standalone server you will definitely not want Wildfly 
dependencies, and probably won't want to bring in all of Picketlink either.

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.

Stuart



> Filter implementations can implement the SecurityContext interface
> themselves and override it for the request.  Really really simple.
> Undertow doesn't have to support much, and yet you have a lot of
> flexibility.  You're letting the security plugin given Undertow what it
> needs to execute securely instead of guessing what SPI the security
> plugin might need to run.
>
> Combine this with Stuarts idea of a "feature" component that can be
> bound via the auth-method and you have an extremely simple yet powerful SPI.
>
> Am I making any sense?
>
> On 5/30/2013 1:59 PM, Jason Greene wrote:
>> One thing I want to stress, is that Undertow was intended to be usable as a standalone project, and it should be possible for someone like Bill to develop an OAuth solution on it that he can run through a unit test. It's perfectly reasonable to have certain advanced features be AS only, but the project itself still needs to provide support for security.
>>
>> This could very well mean we have a few duplicative SPIs, but as long as we do not have a performance penalty and they don't prevent the use of proper AS integration I just don't see a problem with them.
>>
>> On May 30, 2013, at 12:33 PM, Darran Lofthouse<darran.lofthouse at jboss.com>  wrote:
>>
>>> Hello all,
>>>
>>> Starting this e-mail thread as I want to raise the option of reducing
>>> the use of the IdentityManager [1] within Undertow[2].  At the moment I
>>> think it at risk of becoming another general purpose IDM API/SPI which
>>> was never it's intention.
>>>
>>> The purpose of this IdentityManager was as an SPI to define the
>>> verification methods required by the authentication mechanisms included
>>> in Undertow.  By providing it in this way the core of Undertow would not
>>> be dependent on any specific IDM implementation.
>>>
>>> Short term within WildFly we have implementations of this that wrap by
>>> the management security realms and the existing JAAS domains - longer
>>> term we will only be wrapping PicketLink IDM.
>>>
>>> In the past the question has been raised, "Why not just use PicketLink
>>> IDM directly?".  From an Undertow perspective the reason is so that we
>>> can use different IDM implementations and transition from what we have
>>> today in WildFly to purely using PicketLink IDM, also the core of
>>> Undertow is not dependent on any specific implementation.
>>>
>>> For any additional authentication mechanisms being added there is no
>>> need for them to use this as an API and encouraging mechanisms to use
>>> this encourages that this interface is going to increase in complexity.
>>>
>>> What I am looking to do now is to remove access to this interface from
>>> the SecurityContext and instead leave it to be retrieved as an
>>> attachment from the HttpServerExchange.  The WildFly integration will
>>> then take on the responsibility of ensuring the appropriate
>>> implementation is attached to the exchange.
>>>
>>> Where authentication mechanisms are added that require access to more
>>> advanced IDM capabilities then the IDM required should be attached to
>>> the exchange and the mechanism use it directly.
>>>
>>>   From an Undertow perspective this just leaves one small interface that
>>> needs to be implemented so that the authentication mechanism can
>>> register the authenticated identity with the current request: -
>>>
>>> void authenticationComplete(final Account account, final String
>>> mechanismName);
>>>
>>> As I type this e-mail I realise I may have one further option - remove
>>> the IdentityManager interface entirely and instead make each
>>> authentication mechanism abstract with a verify method.  As we integrate
>>> in WildFly we extend each mechanism to provide the implementation of the
>>> verify methods.
>>>
>>> Either way I do not think Undertow is the correct location for a new
>>> general purpose IdentityManager API, if we truly need that then it
>>> should be split out into it's own module so that it can also be used
>>> outside of HTTP e.g. SASL.
>>>
>>> Regards,
>>> Darran Lofthouse.
>>>
>>> 1 - https://community.jboss.org/wiki/Undertow-IdentityManager
>>> 2 - https://issues.jboss.org/browse/UNDERTOW-65
>>> _______________________________________________
>>> undertow-dev mailing list
>>> undertow-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/undertow-dev
>> --
>> Jason T. Greene
>> WildFly Lead / JBoss EAP Platform Architect
>> JBoss, a division of Red Hat
>>
>>
>> _______________________________________________
>> undertow-dev mailing list
>> undertow-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/undertow-dev
>>
>


More information about the undertow-dev mailing list