Hi Darren,

FYI, here are my responses to your original set of comments, which I incorporated/addressed addressed as described below in the PRD draft.

I thought I had sent this out earlier, but just found it sitting in my drafts folder.

Regards,

Will

Just having a pass through EDR1 and here are some comments so far.

* Section 2.1 *

The callers proof of identity is being described as a token or credential, I think it may be more accurate to somehow include response to a challenge in there.  As an example with HTTP Digest, the response is not a credential and I think describing it as a token is pushing the meaning of token.

I agree with your point that a challenge response isn't precisely a token or credential, but that particular passage (if I've got the right one), is meant to be descriptive in a general way, not prescriptive or limiting. I think trying to insert "response to a challenge" into the sentence would break up the flow of the paragraph and potentially make it less understandable.

* HttpAuthenticationMechanism *

I have raised this previously but I still think by including both request validation and challenge generation in a single method there is a missing option to support multiple authentication mechanisms concurrently - a common example I see is CLIENT_CERT with SPNEGO with one or more form of username /password authentication.

I wasn't involved in the previous discussions, and at this point in the JSR I don't think big changes are viable. That said, I think that aspect of HAMs largely derives from the way JASPIC works -- there's a single Server Auth Module invoked for any given request. The solution, as for JASPIC, would be to write a wrapper HAM that could invoke on a set of HAMs until one succeeded, remembering which one succeeded in the case that a challenge was issued (so that the correct HAM could be invoked to respond to the challenge). I agree that's not a completely satisfying solution, though.

Outside of this we have needed to solve a number of additional issues related to HTTP authentication such as unsolicited authentication, caching of an authentication result without undermining the mechanism, having the authenticated available when unsecured resources subsequently accessed.

I may not completely understand all the implications of what you're suggesting, but HAMs should be able to handle unsolicited credentials. Not sure I understand the caching scenario. Having a previous authentication available when accessing unsecured resources I think is a session management problem, and the JSR doesn't really address session management, but I agree that setting up session cookies such that they are both secure and available to unsecured resources is both tricky and necessary.

* Identity Store *

We have been working through some similar issues with the WildFly Elytron project we are currently integrating into WildFly.  So that we can support many different authentication mechanisms we have reached the point where our equivalent of an identity store can be used to both obtain a credential representation that a mechanism can use to verify the response that it has received and an alternative approach where a mechanism can pass in evidence for verification.

Looking at the current proposed API for IdentityStore I am not so sure it is a credential being verified, rather it is verifying either a response to a challenge or a token.

That first comment may be more about relating the API to terminology but the big risk with this is that the implementation details from the authentication mechanism now start to leak into the identity store implementation.  So in addition to being able to interact with the store of identities the store now needs to be aware of the requirements of different mechanisms if it was to be re-usable.

Related to this, as an application server vendor - to provide a default implementation of this interface I would assume a default set of supported credential types would need to be listed somewhere?

I think the most common case for IdentityStore will be verifying a UsernamePasswordCredential, as it's explicity dealing with a user store. IdentityStores can't really deal with challenge/response protocols; that would be handled by a HAM, which would invoke on the IdentityStore{Handler} only at the point that the dialog with the client is finished and the final token or credential that identifies the user is available.

The only required credential to support would be UsernamePasswordCredential.

I will have another pass through the APIs but these are some of the main points that jumped out so far related to issues that we have needed to work through ourselves.

Thanks, Darran -- appreciate you taking the time to look at this.

Regards,
Darran Lofthouse.

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

Hi Darren,

Sorry for not resonding to this sooner, my filter was no longer set up to find "[jsr375-experts]" email ...

Will

On Thu, 6 Jul 2017 at 19:29 Will Hopkins <will.hopkins@...> wrote:

Hi Darren,

FYI, here are my responses to your original set of comments, which I incorporated/addressed addressed as described below in the PRD draft.

I thought I had sent this out earlier, but just found it sitting in my drafts folder.

Regards,

Will

On 03/20/2017 03:16 PM, Darran Lofthouse wrote:

Just having a pass through EDR1 and here are some comments so far.

* Section 2.1 *

The callers proof of identity is being described as a token or credential, I think it may be more accurate to somehow include response to a challenge in there.  As an example with HTTP Digest, the response is not a credential and I think describing it as a token is pushing the meaning of token.

I agree with your point that a challenge response isn't precisely a token or credential, but that particular passage (if I've got the right one), is meant to be descriptive in a general way, not prescriptive or limiting. I think trying to insert "response to a challenge" into the sentence would break up the flow of the paragraph and potentially make it less understandable.

Going through the later spec version I think this is now described differently in two locations, the first definition seems to be about credentials but the later description does go into more details about responses to challenges.

Do you think that's sufficient, or is there still a change you'd like to see (I plan to publish a PFD update shortly)?

* HttpAuthenticationMechanism *

I have raised this previously but I still think by including both request validation and challenge generation in a single method there is a missing option to support multiple authentication mechanisms concurrently - a common example I see is CLIENT_CERT with SPNEGO with one or more form of username /password authentication.

I wasn't involved in the previous discussions, and at this point in the JSR I don't think big changes are viable. That said, I think that aspect of HAMs largely derives from the way JASPIC works -- there's a single Server Auth Module invoked for any given request. The solution, as for JASPIC, would be to write a wrapper HAM that could invoke on a set of HAMs until one succeeded, remembering which one succeeded in the case that a challenge was issued (so that the correct HAM could be invoked to respond to the challenge). I agree that's not a completely satisfying solution, though.

The situation however is slightly more complex  - we would need multiple HAMs to be able to send a response concurrently - when handling the response in the event of a success we would need to clear any responses sent by the other HAMs.  Maybe wrapping the HttpServletResponse could be sufficient to cope with this.

It's inherently complex to support multiple methods that each require challenge/response, I think. For typical cases like BASIC and CERT, it's mostly a matter of choosing among credentials that may already be in the request, with perhaps one option that involves a challenge. But I think your suggestion of wrapping Request/Response is viable.

Outside of this we have needed to solve a number of additional issues related to HTTP authentication such as unsolicited authentication, caching of an authentication result without undermining the mechanism, having the authenticated available when unsecured resources subsequently accessed.

I may not completely understand all the implications of what you're suggesting, but HAMs should be able to handle unsolicited credentials. Not sure I understand the caching scenario. Having a previous authentication available when accessing unsecured resources I think is a session management problem, and the JSR doesn't really address session management, but I agree that setting up session cookies such that they are both secure and available to unsecured resources is both tricky and necessary.

I think the main point being that with the current API the HAM needs to be called for all resources so it can handle it's own caching.  The main point it deciding if a challenge needs to be sent of if a request can be allowed through without authentication.

I think JASPIC specifies that SAMs are called for every request (whether the resource is protected or not). JASPIC is really a message processing protocol that can perform authentication, rather than an authentication mechanism with a concept of protected and non-protected resources.

* Identity Store *

We have been working through some similar issues with the WildFly Elytron project we are currently integrating into WildFly.  So that we can support many different authentication mechanisms we have reached the point where our equivalent of an identity store can be used to both obtain a credential representation that a mechanism can use to verify the response that it has received and an alternative approach where a mechanism can pass in evidence for verification.

Looking at the current proposed API for IdentityStore I am not so sure it is a credential being verified, rather it is verifying either a response to a challenge or a token.

That first comment may be more about relating the API to terminology but the big risk with this is that the implementation details from the authentication mechanism now start to leak into the identity store implementation.  So in addition to being able to interact with the store of identities the store now needs to be aware of the requirements of different mechanisms if it was to be re-usable.

Related to this, as an application server vendor - to provide a default implementation of this interface I would assume a default set of supported credential types would need to be listed somewhere?

I think the most common case for IdentityStore will be verifying a UsernamePasswordCredential, as it's explicity dealing with a user store. IdentityStores can't really deal with challenge/response protocols; that would be handled by a HAM, which would invoke on the IdentityStore{Handler} only at the point that the dialog with the client is finished and the final token or credential that identifies the user is available.

I think as the IdentityStore is optional this can be handled. 

 

The only required credential to support would be UsernamePasswordCredential.

OK.

I think it feels to me the IdentityStore is something you would use just for clear text password verification, once your HAM moves on to more advanced mechanisms then it becomes more appropriate to inject something else.

Agree.

In my mind the distinction isn't between password vs. other (e.g., certificate) types of credentials, per se, it's the distinction between a credential that proves my identity, to the satisfaction of the identity provider with whom I have an account, and a token provided by some third party that does not, in itself, provide direct proof of my identity.

Credential validation as performed by an identity store necessarily involves me proving my identity to the store, and therefore requires a type of credential that can validate my identity, like a password or a 2FA token.

In contrast, a SAML assertion, or OAuth2 token, or even a kerberos TGT, is essentially an assertion by a third party that I have proved my identity to *them*, and the token presented contains no direct proof of my identity. Acceptance of the token is based on a trust relationship with the third party, and the proof element (signature, etc.) relates to proving the identity of the third party -- not me -- and the integrity of the token itself.

I will have another pass through the APIs but these are some of the main points that jumped out so far related to issues that we have needed to work through ourselves.

Thanks, Darran -- appreciate you taking the time to look at this.

Regards,
Darran Lofthouse.

-- 
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