10:47 a.m.
Thanks for your comments Anil.
On 03/12/2013 03:32 PM, Anil Saldhana wrote:
Darran,
I like all the options you have put forward here. Would you create a
wiki article with the
design choices you are outlining?
Yes unless I get some comments back saying we should be going in a
completely different direction I will get this into a Wiki so we can
also start to build on some of configuration areas I mention.
Also answers inline.
On 03/12/2013 08:44 AM, Darran Lofthouse wrote:
> Initially the integration will be with the existing JAAS domains as that
> is what exists today, once we have PicketLink available in a subsystem
> and the work David is working on regarding identity/request association
> then we will also migrate to those as well.
JAAS can be one of the authentication mechanisms. Ideally we should
look at providing an SPI. I presume we will have an SPI.
To clarify some of the terminology I am using here when I talk about a
mechanism I am talking about the part that is sending and parsing the
HTTP messages for challenges and responses.
The PicketLink / JAAS discussion is more about the backing store to
verify the response from the client - but yes Undertow has a simple IDM
API of it's own - this is still being refined but the idea being
initially when integrated with AS this will wrap the existing JAAS
domains - as PicketLink IDM becomes available we will write a second
implementation that wraps PicketLink.
Also to clarify the reason we have currently taken this approach is so
that Undertow does not need any dependencies defining on IDM solutions -
as we integrate within AS8 we can provide the IDM integration as well.
Both implementations will then potentially be available especially for
any legacy JAAS support that we need to retain.
> Users are already used to providing a lot of their configuration
within
> the deployments - maybe even including PicketLink definitions where they
> do not want to use definitions defined within the AS config.
The configuration in the web app deployment should only be used to
override the configuration in the domain model IMO.
The PicketLink portion of this I think is going to need to be a full
discussion in it's own right - I believe there are also plenty of
engineers with opinions regarding where this needs to be configured.
> * Legacy Valve Support *
>
> I am also working on wrapping existing valves so that they can be used
> within Undertow when deployments are deployed to AS8 - however I see
> this as an alternative to the mechanisms supported by Undertow.
>
> As a valve would be used for legacy compatibility this would mean that
> previous functionality can be retained but moving forwards for better
> integration the valve would need to be migrated.
Very low priority. Maybe for backwards compatibility. But this will mean
you will be getting a lot of the older web code. If they have to deploy
a legacy
valve, why not they rewrite the valve to the newer SPI?
Ideally that is what they should be doing - I am not planning to go
beyond getting the valves to work as they do now. This is really to
cover the cases where valve support could become a barrier to migration.