Re: [jboss-as7-dev] Management Console JDK Server Example
On 01/20/2011 07:43 PM, Jason T. Greene wrote:
On 1/20/11 11:02 AM, ssilvert(a)redhat.com wrote:
> Quoting Jason Greene<jason.greene(a)redhat.com>:
>> On Jan 20, 2011, at 7:55 AM, ssilvert(a)redhat.com
wrote:
> >>> I don't want to reinvent the Servlet API
either.
> > >> It's not reinventing
the servlet API, it's using an alternative one
>> that accomplishes then same thing but with minimal overhead.
> If that can really be achieved in a reasonable time frame
then I'm all
> for it. I'm just skeptical at the moment.
> Heiko's point about needing a robust security layer
like JAAS is a
> pretty good one.
So servlet containers give you a set of pre-established authentication
mechanisms:
- Basic
Implemented in the embedded server (Although this one is very easy to
write even if we had to do it)
- Digest
Digest causes problems in multi-layer auth scenarios since its
designed around 2-party communication. Although we could still use it
regardless, granted it requires more work than a servlet container (you
have to implement an Authenticator to do it)
- Cert
The embedded server provides the hooks to use JSSE for establishing
the connection. There you can tell it to require a Cert. You would then
implement an Authenticator that just read the cert off the current
SSLSession and passed it off to JAAS or picketlink or whatever
- Form
This form of auth is pretty much useless. Almost everyone prefers
something custom to the cookie-cutter servlet form
To go beyond these things you have to either not use servlet security
(and instead do custom servlet filters) OR write a container specific
plugin (like a tomcat valve). Once you get to this point it's equivalent
to implementing security directly.
Also, keep in mind that most likely the DC will have to be the one doing
the "true" authentication, or at least redundant authentication. The
primary reason for this is both auditing, and to allow the same
credentials to be used via the CLI and the web app. So this means the DC
will already have to be written to auth somehow (using picketlink or
whatever)
Yes especially if we implement a GWT console that is calling one of the
admin interfaces directly the security requirements for the console
become minimal (The question for the console is then how to pass in the
users credentials most likely from the list above and secondly how the
console can determine what the user can actually access) - what we are
really looking for is securing the common entry point so we only need to
implement it once and also so that the security is consistent.
We don't want to end up in a situation where a user is restricted by one
mechanism but can work around the security by using another.