[undertow-dev] Reducing Use of Undertow IdentityManager

[Darran Lofthouse]

There were quite a few replies overnight so I am just going to reply to 
my original mail rather than pick one ;-)

As I said in my first e-mail the classes that exist are definitely an 
SPI but there does seem to be a lot of support for keeping it available 
as an API to be usable at least to cover the mechanisms within Undertow 
and the OAuth requirements from Bill.

If that is the case I suggest we split this out into it's own module as 
it should not be specific to Undertow / HTTP.  We have said for a while 
we want to move the SASL mechanisms on from CallbackHandlers as well.

Projects developing IDM solutions such as PicketLink IDM can then just 
depend on this API/SPI and create their own implementation.

Both Undertow and Remoting / SASL can make use of this.

So if we went in this direction where should we live, this would not be 
specific to any of: -
  - PicketLink
  - Remoting
  - SASL
  - Undertow
  - WildFly

Regards,
Darran Lofthouse.


On 30/05/13 18:33, Darran Lofthouse 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
>