Thanks for all the help Paul.
As it turns out, I've learned quite a bit today about how servlet
authentication works. Apparently, the login-config tag indicates a
method that the container should use to authenticate users. However, the
realm must be configured using whatever mechanisms are available from
the container to define users and their credentials. As an example,
Jetty provides an interface called UserRealm, from which a couple of
implementations extend: HashUserRealm and JDBCUserRealm. The first is a
simple file based system much like the old unix password file. The
second is based on a defined set of SQL tables containing user
information. I imagine all servlet containers implement a couple of
basic forms of something like UserRealm.
Ultimately, though, the problem I was facing was that it all required a
fair amount of configuration in the servlet container's configuration
file (server.xml, jetty.xml, whatever). I didn't have that luxury, so
what I ended up doing was simply accessing the X509Certificate attribute
in the ServletRequest (per your instructions, thank you). Then I did my
own user authentication by reading the single user name from a property
file.
Thanks again for all the help. I sure wish this stuff were better
documented. I spent hours searching Google yesterday for basic
information on the login process and found very little. Most of what I
found assumed you already knew the basics (which I didn't).
John
On 9/10/2010 3:31 AM, Paul Sandoz wrote:
> Hi John,
>
> I dunno enough about Jetty but i would expect something like this in
> the web.xml:
>
> <login-config>
> <auth-method>CLIENT-CERT</auth-method>
> <realm-name>certification</realm-name>
> </login-config>
>
> But i dunno what the realm name should be for your set up.
>
> Note that Jersey defers to the HttpServletRequest to obtain the
> security information.
>
> Perhaps you need to ask on the Jetty forum?
>
> Paul.
>
> On Sep 9, 2010, at 5:11 PM, John Calcote wrote:
>
>> Hi Paul,
>>
>> Thanks for the response. I'm using Jetty (6.1.22), but I've had some
>> experience using certs, so I'm familiar with what needs to be done in
>> the server-side trust and key stores. I've enabled SSL in Jetty and
>> configured server-side stores. I've also enabled want-client-cert in the
>> SSL connector so that the server requests the cert from the client (but
>> doesn't demand it).
>>
>> In my earlier comments, I mentioned that I'd noticed an SSL exception
>> (in the log) on access before I added the client cert to the server's
>> truststore. Once I did that, the exception went away. Thus, I know that
>> the SSL layer is (probably) correctly processing the certificate
>> exchange.
>>
>> What I don't know how to do is get the cert from the SSL layer up to the
>> application layer in the form of an authenticated principal. I did a bit
>> more research and discovered the web.xml login-config element and its
>> child element, auth-method. Setting auth-method to CLIENT-CERT should
>> probably have done the trick, but it didn't seem to help - the result of
>> a call to getUserPrincipal on the request object still produces a null
>> reference. I'm thinking there must be a bit more to it than just using
>> the login-config element.
>>
>> Thanks,
>> John
>>
>> On 9/9/2010 4:48 AM, Paul Sandoz wrote:
>>> Hi John,
>>>
>>> What Web container are you using? I think you may need to register the
>>> cert on the server side as well.
>>>
>>> Paul.
>>>
>>> On Sep 9, 2010, at 1:50 AM, John Calcote wrote:
>>>
>>>> I've managed to successfully install a ContainerRequestFilter that
>>>> currently just displays (logs) the principal via
>>>> ContainerRequest.getUserPrincipal(). When I tested, I found I was
>>>> getting an SSL exception - unknown cert (from my browser). I installed
>>>> my browser's cert into the truststore, and the SSL error went away,
>>>> but
>>>> the Principal returned is still null.
>>>>
>>>> What do I have to do in Jersey/Spring to get the request's Principal
>>>> object to be populated with the X.509 certificate identity
>>>> (subjectName,
>>>> or whatever)? Clearly, I'm missing some wiring here.
>>>>
>>>> Thanks,
>>>> John
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
>>>> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
>>> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>>>
>>>
>>
>
>