[jboss-as7-dev] Management Console JDK Server Example

[Darran Lofthouse]

On 01/20/2011 07:43 PM, Jason T. Greene wrote:
> On 1/20/11 11:02 AM, ssilvert at redhat.com wrote:
>> Quoting Jason Greene<jason.greene at redhat.com>:
>>
>>> On Jan 20, 2011, at 7:55 AM, ssilvert at 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.

>