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.
* 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,
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.
* 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.
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.
* 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.
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.
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 07/06/2017 06:05 PM, Darran
Lofthouse 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
|
|