[security-dev] [jboss-as7-dev] Web Application - Security Mechanism Selection

[Darran Lofthouse]

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.