[security-dev] [jboss-as7-dev] Web Application - Security Mechanism Selection
darran.lofthouse at jboss.com
Tue Mar 12 11:47:34 EDT 2013
Thanks for your comments Anil.
On 03/12/2013 03:32 PM, Anil Saldhana wrote:
> 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.
More information about the security-dev