Topics

Built In HttpAuthenticationMechanismBeans - Client Cert


Darran Lofthouse
 

Just a small one.

Is there a reason for omitting a bean for client cert authentication?

If a client's certificate is available the servlet container is required to make it available so we have access to it so it would seem the majority of the impl would be about wrapping it in a standard credential type and passing it to the IdentityStore for validation.

From the latest spec and the conversations this week it seems the primary purpose of the IdentityStore is going to be when working with the built in mechanisms but wanting to swap in a different store implementation - this would seem a good one to be able to support.

Regards,
Darran Lofthouse.


Arjan Tijms
 

Hi, 

There's no specific reason to omitting this, other than time again and perhaps that nobody asked for it yet (which is not a very good reason, I agree).

This is probably small enough and isolated enough to still include, so if Will agrees I may give it a shot (or feel free to do a PR for this).

Kind regards,
Arjan Tijms


Will Hopkins
 

I'm willing to consider a PR for it. Certainly adding a certificate credential that identity stores could choose to support is straightforward. In practice I'm not sure a separate built-in HAM annotation for it (like the BASIC/FORM builtins) would be practical, as implementations tend to provide CERT as an adjunct or backup to the other two, but we could provide an option that tells FORM or BASIC to process a cert if username/password isn't seen ...

On 07/07/2017 07:58 AM, Arjan Tijms wrote:
Hi, 

There's no specific reason to omitting this, other than time again and perhaps that nobody asked for it yet (which is not a very good reason, I agree).

This is probably small enough and isolated enough to still include, so if Will agrees I may give it a shot (or feel free to do a PR for this).

Kind regards,
Arjan Tijms

-- 
Will Hopkins | WebLogic Security Architect | +1.781.442.0310
Oracle Application Development
35 Network Drive, Burlington, MA 01803


Darran Lofthouse
 

The servlet spec has always regarded it as an independent mechanism on it's own so in your web.xml you would specify CLIENT_CERT and not support any form of username / password auth for that deployment - if these built in types represent an alternative to web.xml configuration I think it could be reasonable to support it on it's own.

Allowing the FORM and BASIC mechs additionally to use a cert if available and no credentials received would actually help with the concern I raised about the multi mech support is this is one of the scenarios I have been asked about in the past. 

On Fri, 7 Jul 2017 at 16:28 Will Hopkins <will.hopkins@...> wrote:
I'm willing to consider a PR for it. Certainly adding a certificate credential that identity stores could choose to support is straightforward. In practice I'm not sure a separate built-in HAM annotation for it (like the BASIC/FORM builtins) would be practical, as implementations tend to provide CERT as an adjunct or backup to the other two, but we could provide an option that tells FORM or BASIC to process a cert if username/password isn't seen ...


On 07/07/2017 07:58 AM, Arjan Tijms wrote:
Hi, 

There's no specific reason to omitting this, other than time again and perhaps that nobody asked for it yet (which is not a very good reason, I agree).

This is probably small enough and isolated enough to still include, so if Will agrees I may give it a shot (or feel free to do a PR for this).

Kind regards,
Arjan Tijms

-- 
Will Hopkins | WebLogic Security Architect | +1.781.442.0310
Oracle Application Development
35 Network Drive, Burlington, MA 01803


Will Hopkins
 

Actually, the more I think about it, I don't think we can get this in. The existing servlet mechanism will continue to be there, and I think there's enough compexity here that I don't feel comfortable trying to add it in at the last minute -- although I do agree it would be useful, and that consistency with existing servlet behavior would be good.

On 07/07/2017 11:33 AM, Darran Lofthouse wrote:
The servlet spec has always regarded it as an independent mechanism on it's own so in your web.xml you would specify CLIENT_CERT and not support any form of username / password auth for that deployment - if these built in types represent an alternative to web.xml configuration I think it could be reasonable to support it on it's own.
True enough, although I think applications that use client cert on its own, vs. just making the client cert available in conjunction with primary authentication based on BASIC or FORM, is relatively rare.


Allowing the FORM and BASIC mechs additionally to use a cert if available and no credentials received would actually help with the concern I raised about the multi mech support is this is one of the scenarios I have been asked about in the past. 

On Fri, 7 Jul 2017 at 16:28 Will Hopkins <will.hopkins@...> wrote:
I'm willing to consider a PR for it. Certainly adding a certificate credential that identity stores could choose to support is straightforward. In practice I'm not sure a separate built-in HAM annotation for it (like the BASIC/FORM builtins) would be practical, as implementations tend to provide CERT as an adjunct or backup to the other two, but we could provide an option that tells FORM or BASIC to process a cert if username/password isn't seen ...


On 07/07/2017 07:58 AM, Arjan Tijms wrote:
Hi, 

There's no specific reason to omitting this, other than time again and perhaps that nobody asked for it yet (which is not a very good reason, I agree).

This is probably small enough and isolated enough to still include, so if Will agrees I may give it a shot (or feel free to do a PR for this).

Kind regards,
Arjan Tijms

-- 
Will Hopkins | WebLogic Security Architect | +1.781.442.0310
Oracle Application Development
35 Network Drive, Burlington, MA 01803

-- 
Will Hopkins | WebLogic Security Architect | +1.781.442.0310
Oracle Application Development
35 Network Drive, Burlington, MA 01803