Hi,
For comments, see below:
On Fri, Apr 7, 2017 at 5:16 PM, Ajay Reddy <areddy_at_us.ibm.com> wrote:
> I was thinking more from a client point of view (eg browser). If at the
> end of the authentication, if INVALID is thrown by the validate method,
> there might be a re-prompt for the client to re-enter the credentials
> (because may be the password was incorrect). If NOT_VALIDATED is thrown
> (none of the stores are capable of validating the given credential), is
> there anything the container need to indicate to the client?
>
From the point of view of the identity store the browser wouldn't matter,
since all the store does is validating the credential in an almost
functional way.
The caller (user) and on its behalve the browser (http protocol) doesn't
interact with the identity store directly at all.
What does interact with the identity store is the authentication mechanism,
which is what handles the interaction with the caller and delegates the
pure credential validation function to the identity store.
If the identity store returns INVALID, then it's the authentication
mechanism's task to translate that into the proper response to the caller.
Indeed, in a (custom) form authentication mechanism this could do such
things as redirect to an error page, display the same login page again but
with errors, and what have you. For other authentication mechanisms such as
a token mechanism for web services returning a 403 right away might be more
appropriate.
If the final outcome of consulting all available identity stores is
NOT_VALIDATED, it's likely a system level error; a system configuration
error in this case. Again, it depends on the authentication mechanism
that's configured what's returned to the caller. The mechanism could decide
to throw a 500 internal server error or threat it just as if the credential
was invalid.
One of other reasons for being optional is because I am not sure if any
> specification can (or has) dictated a specific repository to be supported
> by a container. Yes, containers do support multiple stores based on
> customer needs but it is upto to the container.
>
Indeed, that's the way things used to be. JSR 375 however defines a number
of portable build-in identity stores. These do not depend on the container
but are mandated to be supported. These are
the DataBaseIdentityStore, EmbeddedIdentityStore, and LdapIdentityStore.
I know Will strives to not have any more additions to the spec, but it may
be a very good idea to add the NativeIdentityStore here too, which would be
just a placeholder to tell the implementation to use whatever native
(container specific) identity store is configured using whatever container
specific configuration.
> > Alternatively we could warn that the list of roles is only valid for
> > the moment it has been requested and from the context which it is
> > requested. Note this is conceptually not much different from storing
> > the result of a request.isUserInRole call and re-using that outcome
> later.
>
> Not having a dependency on JACC is a good thing. Thanks Will :-)
>
I don't entirely agree ;)
I know there's fear for JACC and its perceived complexity, but just a few
tweaks and convenience methods left and right can make it a very useful and
powerful thing.
JACC is basically a management system for authorization rules, which really
allows for very powerful things.
For example, take a look at this article:
http://arjan-tijms.omnifaces.org/2016/07/simplified-custom-authorization-rules.html
> Ya, I was thinking about .ear files that could contain global roles that
> may not be applicable to this webapp. Something we need to clarify. So wrt
> to a WAR app, this would return all the assigned roles for the caller - not
> all roles in the app?
>
It's indeed the roles assigned to a caller, i.e. for each role in that set
or list, calling isCallerInRole would have to return true (in the same
context, obviously).
> I guess just having them pass the URLs here should be fine - i.e just
> boolean hasAccessToWebResource(String resourceURL)?
>
Indeed, with the same patterns supported as defined for the input of that
permission.
The spec for that method can reference the WebResourcePermission type for
the full definition of this pattern (the urlPatternSpec).
But a simple example is:
securityContext.hasAccessToWebResource("/protectedServlet")
Given a Servlet definition like:
@WebServlet("/protectedServlet")
@ServletSecurity(@HttpConstraint(rolesAllowed = "foo"))
public class ProtectedServlet extends HttpServlet { ... }
The above "hasAccessToWebResource" call would return true if and only if
the caller is in role "foo".
Kind regards,
Arjan Tijms
>
>
> >
> > Kind regards,
> > Arjan Tijms
> >
> >
> >
> >
> > Will have to investigate these more but wanted to understand the
> > usage/use cases first.
> >
> > Thanks for your time.
> >
> >
> > Regards,
> > Ajay Reddy
> >
>
>