You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Antony Bowesman <ad...@teamware.com> on 2001/11/05 12:25:11 UTC
Client-Cert authentication with Tomcat 4
Hi,
I have followed the comments in server.xml to get SSL working and have
set up the security example to have client-cert as the auth method in
web.xml. When I first connect to my host, the browser asks which
certificate I want to send. However, the browser then prompts me for a
username/password (as in basic authentication) when I try to connect to
the protected page.
I am using my own realm, however, from the Realm code, it seems that
none of the realm implementations (including my own) implement the
abstract getPrincipal)() method in RealmBase.java, i.e. they all return
null so it seems that this will never work with the supplied realms.
Am I missing something, does anyone have this working?
Rgds
--
Antony Bowesman
Teamware Group
adb@teamware.com
phone: +358 9 5128 2562
fax : +358 9 5128 2705
intra / extra / Internet solutions at www.teamware.com
--
To unsubscribe: <ma...@jakarta.apache.org>
For additional commands: <ma...@jakarta.apache.org>
Troubles with the list: <ma...@jakarta.apache.org>
Re: Client-Cert authentication with Tomcat 4
Posted by Antony Bowesman <ad...@teamware.com>.
Tim,
Very clearly put, however...
Timothy Fisher wrote:
>
> I think your confusing a few elements.
Quite likely :)
> In a client-cert authentication mechanism, the fact
> that you possess the private key associated with the
> certificate is what is used to authenticate you. This
> is a much stronger security policy than a pure
> password authentication scheme.
but it doesn't prove that you are entitled to hold that key.
> Antoher point of clarification, passwords are not used
> to encrypt/decrypt the certificates. They are used to
> protect (encrypt/decrypt) the private key. The
> private key is the key to the security of this
> mechanism. The certificate itself can be made public
> with no dire consequences. In fact, it is often
> advantageous to make the certificate publicly
> available.
>
> Comparing client-cert with a password scheme, such as
> form or digested.
>
> - with client-cert, you must have possession of the
> private key and the passoword protecting it. This is
> 2-factor authentication.
> - with form and digest mechanisms, you only need to
> know/guess the password. This is single factor
> authentication.
With client-cert you just have to guess the browser password, at that
point you have access to all the systems that recognise the key.
> - with form/digest mechanisms, the passwords or a
> digested form of them must be centrally stored. This
> always adds another security risk, and eliminates the
> possibility of achieving non-repudiation.
> - with client-cert, the password needs to reside NO
> WHERE except in the private key owners head. There is
> no central authority that needs to have any knowledge
> of the password.
> - form/digest mechanisms are not scalable. They can
> only be used to authenticate with users who already
> know them (i.e. know a form of their password for
> checking against)
> - with client-cert, you can authenticate against any
> server. There does not have to be any pre-established
> relationship.
>
> If you have the capability of choosing between
> client-cert and digest/form based authentication,
> client-cert is vastly more secure.
I agree with most of your points about storage of password, but given
current browser technology there is no mechanism to force things such as
minumum length, password rotation and required password changes whereas
this may be possible in the server. It seems like client-cert combined
with form/digest mechanism would provide the most secure means.
Antony
>
> --- Antony Bowesman <ad...@teamware.com> wrote:
> > Thanks Richard, that made things clearer. I was
> > confused by statements
> > such as
> >
> > "Currently the most robust form of client
> > authentication"
> >
> > as in many cases the accompanying phrase
> >
> > "as long as physical access to the private key (and
> > the computer where
> > it is stored) is restricted to the user who owns the
> > key"
> >
> > was not included.
> >
> > Antony
> >
> > Richard Troy wrote:
> > >
> > > Antony,
> > >
> > > unless I'm mistaken, and I could be, the password
> > on the client side is
> > > used for encrypting and decrypting the clients
> > certificate. When the
> > > certificate is first created, the password is
> > given. without the password,
> > > there's no authentication that the user of the
> > certificate really is the
> > > user, so it's required. This puts confidence of
> > the certificates
> > > authenticity in the hands of the user - it's no
> > more nor any less secure
> > > than any other password scheme, except as you
> > point out, there's no way
> > > for the server-side to enforce password selection
> > criteria. That would
> > > have to come from the certificate generation
> > process...
> > >
> > > Hope this helps,
> > >
> > > RT
> > >
> > > --
> > > Richard Troy, Chief Scientist
> > > Science Tools Corporation
> > > rtroy@ScienceTools.com, 510-567-9957,
> > http://ScienceTools.com/
> > >
> > > On Tue, 6 Nov 2001, Antony Bowesman wrote:
> > >
> > > > Date: Tue, 06 Nov 2001 08:30:38 +0200
> > > > From: Antony Bowesman <ad...@teamware.com>
> > > > Reply-To: Tomcat Users List
> > <to...@jakarta.apache.org>
> > > > To: Tomcat Users List
> > <to...@jakarta.apache.org>
> > > > Subject: Re: Client-Cert authentication with
> > Tomcat 4
> > > >
> > > > Timothy Fisher wrote:
> > > > >
> > > > > You will get prompted for your password by the
> > browser
> > > > > when using client-cert authentication. The
> > password
> > > > > is necessary to unlock your private key.
> > > >
> > > > Oh yes. It never asked me because it was set to
> > the default of only ask
> > > > the 'first' time the cert is needed. (Netscape)
> > Anyway, it still seems
> > > > odd to delegate password security to the
> > workstation where there is no
> > > > way of an administrator enforced password policy
> > (e.g. min length,
> > > > alpha/numeric, forced changes) such as would be
> > available by a back end
> > > > password mechanism.
> > > >
> > > > Once you have access to the browser via a
> > possibly guessable password it
> > > > gives you access to the powerful certificate
> > with no further
> > > > authentication done by the server to
> > authenticate the user.
> > > >
> > > > I can't see the use for CLIENT-CERT
> > authentication, it seems like form
> > > > or digest authentication over SSL with
> > clientAuth=true set in server.xml
> > > > would achieve better security.
> > > >
> > > > Rgds
> > > > Antony
> > > >
> > > > > > Hi,
> > > > > >
> > > > > > I have followed the comments in server.xml
> > to get
> > > > > > SSL working and have
> > > > > > set up the security example to have
> > client-cert as
> > > > > > the auth method in
> > > > > > web.xml. When I first connect to my host,
> > the
> > > > > > browser asks which
> > > > > > certificate I want to send. However, the
> > browser
> > > > > > then prompts me for a
> > > > > > username/password (as in basic
> > authentication) when
> > > > > > I try to connect to
> > > > > > the protected page.
> > > > > >
> > > > > > I am using my own realm, however, from the
> > Realm
> > > > > > code, it seems that
> > > > > > none of the realm implementations (including
> > my own)
> > > > > > implement the
> > > > > > abstract getPrincipal)() method in
> > RealmBase.java,
> > > > > > i.e. they all return
> > > > > > null so it seems that this will never work
> > with the
> > > > > > supplied realms.
> > > > > >
> > > > > > Am I missing something, does anyone have
> > this
> > > > > > working?
> > > > > >
> > > > > > Rgds
> > > > > > --
> > > > > > Antony Bowesman
> >
> > --
> > To unsubscribe:
> > <ma...@jakarta.apache.org>
> > For additional commands:
> > <ma...@jakarta.apache.org>
> > Troubles with the list:
> > <ma...@jakarta.apache.org>
> >
>
> __________________________________________________
> Do You Yahoo!?
> Find a job, post your resume.
> http://careers.yahoo.com
>
> --
> To unsubscribe: <ma...@jakarta.apache.org>
> For additional commands: <ma...@jakarta.apache.org>
> Troubles with the list: <ma...@jakarta.apache.org>
--
Antony Bowesman
Teamware Group
adb@teamware.com
phone: +358 9 5128 2562
fax : +358 9 5128 2705
intra / extra / Internet solutions at www.teamware.com
--
To unsubscribe: <ma...@jakarta.apache.org>
For additional commands: <ma...@jakarta.apache.org>
Troubles with the list: <ma...@jakarta.apache.org>
Re: Client-Cert authentication with Tomcat 4
Posted by Timothy Fisher <tr...@yahoo.com>.
I think your confusing a few elements.
In a client-cert authentication mechanism, the fact
that you possess the private key associated with the
certificate is what is used to authenticate you. This
is a much stronger security policy than a pure
password authentication scheme.
Antoher point of clarification, passwords are not used
to encrypt/decrypt the certificates. They are used to
protect (encrypt/decrypt) the private key. The
private key is the key to the security of this
mechanism. The certificate itself can be made public
with no dire consequences. In fact, it is often
advantageous to make the certificate publicly
available.
Comparing client-cert with a password scheme, such as
form or digested.
- with client-cert, you must have possession of the
private key and the passoword protecting it. This is
2-factor authentication.
- with form and digest mechanisms, you only need to
know/guess the password. This is single factor
authentication.
- with form/digest mechanisms, the passwords or a
digested form of them must be centrally stored. This
always adds another security risk, and eliminates the
possibility of achieving non-repudiation.
- with client-cert, the password needs to reside NO
WHERE except in the private key owners head. There is
no central authority that needs to have any knowledge
of the password.
- form/digest mechanisms are not scalable. They can
only be used to authenticate with users who already
know them (i.e. know a form of their password for
checking against)
- with client-cert, you can authenticate against any
server. There does not have to be any pre-established
relationship.
If you have the capability of choosing between
client-cert and digest/form based authentication,
client-cert is vastly more secure.
Tim
--- Antony Bowesman <ad...@teamware.com> wrote:
> Thanks Richard, that made things clearer. I was
> confused by statements
> such as
>
> "Currently the most robust form of client
> authentication"
>
> as in many cases the accompanying phrase
>
> "as long as physical access to the private key (and
> the computer where
> it is stored) is restricted to the user who owns the
> key"
>
> was not included.
>
> Antony
>
> Richard Troy wrote:
> >
> > Antony,
> >
> > unless I'm mistaken, and I could be, the password
> on the client side is
> > used for encrypting and decrypting the clients
> certificate. When the
> > certificate is first created, the password is
> given. without the password,
> > there's no authentication that the user of the
> certificate really is the
> > user, so it's required. This puts confidence of
> the certificates
> > authenticity in the hands of the user - it's no
> more nor any less secure
> > than any other password scheme, except as you
> point out, there's no way
> > for the server-side to enforce password selection
> criteria. That would
> > have to come from the certificate generation
> process...
> >
> > Hope this helps,
> >
> > RT
> >
> > --
> > Richard Troy, Chief Scientist
> > Science Tools Corporation
> > rtroy@ScienceTools.com, 510-567-9957,
> http://ScienceTools.com/
> >
> > On Tue, 6 Nov 2001, Antony Bowesman wrote:
> >
> > > Date: Tue, 06 Nov 2001 08:30:38 +0200
> > > From: Antony Bowesman <ad...@teamware.com>
> > > Reply-To: Tomcat Users List
> <to...@jakarta.apache.org>
> > > To: Tomcat Users List
> <to...@jakarta.apache.org>
> > > Subject: Re: Client-Cert authentication with
> Tomcat 4
> > >
> > > Timothy Fisher wrote:
> > > >
> > > > You will get prompted for your password by the
> browser
> > > > when using client-cert authentication. The
> password
> > > > is necessary to unlock your private key.
> > >
> > > Oh yes. It never asked me because it was set to
> the default of only ask
> > > the 'first' time the cert is needed. (Netscape)
> Anyway, it still seems
> > > odd to delegate password security to the
> workstation where there is no
> > > way of an administrator enforced password policy
> (e.g. min length,
> > > alpha/numeric, forced changes) such as would be
> available by a back end
> > > password mechanism.
> > >
> > > Once you have access to the browser via a
> possibly guessable password it
> > > gives you access to the powerful certificate
> with no further
> > > authentication done by the server to
> authenticate the user.
> > >
> > > I can't see the use for CLIENT-CERT
> authentication, it seems like form
> > > or digest authentication over SSL with
> clientAuth=true set in server.xml
> > > would achieve better security.
> > >
> > > Rgds
> > > Antony
> > >
> > > > > Hi,
> > > > >
> > > > > I have followed the comments in server.xml
> to get
> > > > > SSL working and have
> > > > > set up the security example to have
> client-cert as
> > > > > the auth method in
> > > > > web.xml. When I first connect to my host,
> the
> > > > > browser asks which
> > > > > certificate I want to send. However, the
> browser
> > > > > then prompts me for a
> > > > > username/password (as in basic
> authentication) when
> > > > > I try to connect to
> > > > > the protected page.
> > > > >
> > > > > I am using my own realm, however, from the
> Realm
> > > > > code, it seems that
> > > > > none of the realm implementations (including
> my own)
> > > > > implement the
> > > > > abstract getPrincipal)() method in
> RealmBase.java,
> > > > > i.e. they all return
> > > > > null so it seems that this will never work
> with the
> > > > > supplied realms.
> > > > >
> > > > > Am I missing something, does anyone have
> this
> > > > > working?
> > > > >
> > > > > Rgds
> > > > > --
> > > > > Antony Bowesman
>
> --
> To unsubscribe:
> <ma...@jakarta.apache.org>
> For additional commands:
> <ma...@jakarta.apache.org>
> Troubles with the list:
> <ma...@jakarta.apache.org>
>
__________________________________________________
Do You Yahoo!?
Find a job, post your resume.
http://careers.yahoo.com
--
To unsubscribe: <ma...@jakarta.apache.org>
For additional commands: <ma...@jakarta.apache.org>
Troubles with the list: <ma...@jakarta.apache.org>
Re: Client-Cert authentication with Tomcat 4
Posted by Antony Bowesman <ad...@teamware.com>.
Thanks Richard, that made things clearer. I was confused by statements
such as
"Currently the most robust form of client authentication"
as in many cases the accompanying phrase
"as long as physical access to the private key (and the computer where
it is stored) is restricted to the user who owns the key"
was not included.
Antony
Richard Troy wrote:
>
> Antony,
>
> unless I'm mistaken, and I could be, the password on the client side is
> used for encrypting and decrypting the clients certificate. When the
> certificate is first created, the password is given. without the password,
> there's no authentication that the user of the certificate really is the
> user, so it's required. This puts confidence of the certificates
> authenticity in the hands of the user - it's no more nor any less secure
> than any other password scheme, except as you point out, there's no way
> for the server-side to enforce password selection criteria. That would
> have to come from the certificate generation process...
>
> Hope this helps,
>
> RT
>
> --
> Richard Troy, Chief Scientist
> Science Tools Corporation
> rtroy@ScienceTools.com, 510-567-9957, http://ScienceTools.com/
>
> On Tue, 6 Nov 2001, Antony Bowesman wrote:
>
> > Date: Tue, 06 Nov 2001 08:30:38 +0200
> > From: Antony Bowesman <ad...@teamware.com>
> > Reply-To: Tomcat Users List <to...@jakarta.apache.org>
> > To: Tomcat Users List <to...@jakarta.apache.org>
> > Subject: Re: Client-Cert authentication with Tomcat 4
> >
> > Timothy Fisher wrote:
> > >
> > > You will get prompted for your password by the browser
> > > when using client-cert authentication. The password
> > > is necessary to unlock your private key.
> >
> > Oh yes. It never asked me because it was set to the default of only ask
> > the 'first' time the cert is needed. (Netscape) Anyway, it still seems
> > odd to delegate password security to the workstation where there is no
> > way of an administrator enforced password policy (e.g. min length,
> > alpha/numeric, forced changes) such as would be available by a back end
> > password mechanism.
> >
> > Once you have access to the browser via a possibly guessable password it
> > gives you access to the powerful certificate with no further
> > authentication done by the server to authenticate the user.
> >
> > I can't see the use for CLIENT-CERT authentication, it seems like form
> > or digest authentication over SSL with clientAuth=true set in server.xml
> > would achieve better security.
> >
> > Rgds
> > Antony
> >
> > > > Hi,
> > > >
> > > > I have followed the comments in server.xml to get
> > > > SSL working and have
> > > > set up the security example to have client-cert as
> > > > the auth method in
> > > > web.xml. When I first connect to my host, the
> > > > browser asks which
> > > > certificate I want to send. However, the browser
> > > > then prompts me for a
> > > > username/password (as in basic authentication) when
> > > > I try to connect to
> > > > the protected page.
> > > >
> > > > I am using my own realm, however, from the Realm
> > > > code, it seems that
> > > > none of the realm implementations (including my own)
> > > > implement the
> > > > abstract getPrincipal)() method in RealmBase.java,
> > > > i.e. they all return
> > > > null so it seems that this will never work with the
> > > > supplied realms.
> > > >
> > > > Am I missing something, does anyone have this
> > > > working?
> > > >
> > > > Rgds
> > > > --
> > > > Antony Bowesman
--
To unsubscribe: <ma...@jakarta.apache.org>
For additional commands: <ma...@jakarta.apache.org>
Troubles with the list: <ma...@jakarta.apache.org>
Re: Client-Cert authentication with Tomcat 4
Posted by Richard Troy <rt...@ScienceTools.com>.
Antony,
unless I'm mistaken, and I could be, the password on the client side is
used for encrypting and decrypting the clients certificate. When the
certificate is first created, the password is given. without the password,
there's no authentication that the user of the certificate really is the
user, so it's required. This puts confidence of the certificates
authenticity in the hands of the user - it's no more nor any less secure
than any other password scheme, except as you point out, there's no way
for the server-side to enforce password selection criteria. That would
have to come from the certificate generation process...
Hope this helps,
RT
--
Richard Troy, Chief Scientist
Science Tools Corporation
rtroy@ScienceTools.com, 510-567-9957, http://ScienceTools.com/
On Tue, 6 Nov 2001, Antony Bowesman wrote:
> Date: Tue, 06 Nov 2001 08:30:38 +0200
> From: Antony Bowesman <ad...@teamware.com>
> Reply-To: Tomcat Users List <to...@jakarta.apache.org>
> To: Tomcat Users List <to...@jakarta.apache.org>
> Subject: Re: Client-Cert authentication with Tomcat 4
>
> Timothy Fisher wrote:
> >
> > You will get prompted for your password by the browser
> > when using client-cert authentication. The password
> > is necessary to unlock your private key.
>
> Oh yes. It never asked me because it was set to the default of only ask
> the 'first' time the cert is needed. (Netscape) Anyway, it still seems
> odd to delegate password security to the workstation where there is no
> way of an administrator enforced password policy (e.g. min length,
> alpha/numeric, forced changes) such as would be available by a back end
> password mechanism.
>
> Once you have access to the browser via a possibly guessable password it
> gives you access to the powerful certificate with no further
> authentication done by the server to authenticate the user.
>
> I can't see the use for CLIENT-CERT authentication, it seems like form
> or digest authentication over SSL with clientAuth=true set in server.xml
> would achieve better security.
>
> Rgds
> Antony
>
> > > Hi,
> > >
> > > I have followed the comments in server.xml to get
> > > SSL working and have
> > > set up the security example to have client-cert as
> > > the auth method in
> > > web.xml. When I first connect to my host, the
> > > browser asks which
> > > certificate I want to send. However, the browser
> > > then prompts me for a
> > > username/password (as in basic authentication) when
> > > I try to connect to
> > > the protected page.
> > >
> > > I am using my own realm, however, from the Realm
> > > code, it seems that
> > > none of the realm implementations (including my own)
> > > implement the
> > > abstract getPrincipal)() method in RealmBase.java,
> > > i.e. they all return
> > > null so it seems that this will never work with the
> > > supplied realms.
> > >
> > > Am I missing something, does anyone have this
> > > working?
> > >
> > > Rgds
> > > --
> > > Antony Bowesman
>
> --
> To unsubscribe: <ma...@jakarta.apache.org>
> For additional commands: <ma...@jakarta.apache.org>
> Troubles with the list: <ma...@jakarta.apache.org>
>
--
To unsubscribe: <ma...@jakarta.apache.org>
For additional commands: <ma...@jakarta.apache.org>
Troubles with the list: <ma...@jakarta.apache.org>
Re: Client-Cert authentication with Tomcat 4
Posted by Antony Bowesman <ad...@teamware.com>.
Timothy Fisher wrote:
>
> You will get prompted for your password by the browser
> when using client-cert authentication. The password
> is necessary to unlock your private key.
Oh yes. It never asked me because it was set to the default of only ask
the 'first' time the cert is needed. (Netscape) Anyway, it still seems
odd to delegate password security to the workstation where there is no
way of an administrator enforced password policy (e.g. min length,
alpha/numeric, forced changes) such as would be available by a back end
password mechanism.
Once you have access to the browser via a possibly guessable password it
gives you access to the powerful certificate with no further
authentication done by the server to authenticate the user.
I can't see the use for CLIENT-CERT authentication, it seems like form
or digest authentication over SSL with clientAuth=true set in server.xml
would achieve better security.
Rgds
Antony
> > Hi,
> >
> > I have followed the comments in server.xml to get
> > SSL working and have
> > set up the security example to have client-cert as
> > the auth method in
> > web.xml. When I first connect to my host, the
> > browser asks which
> > certificate I want to send. However, the browser
> > then prompts me for a
> > username/password (as in basic authentication) when
> > I try to connect to
> > the protected page.
> >
> > I am using my own realm, however, from the Realm
> > code, it seems that
> > none of the realm implementations (including my own)
> > implement the
> > abstract getPrincipal)() method in RealmBase.java,
> > i.e. they all return
> > null so it seems that this will never work with the
> > supplied realms.
> >
> > Am I missing something, does anyone have this
> > working?
> >
> > Rgds
> > --
> > Antony Bowesman
--
To unsubscribe: <ma...@jakarta.apache.org>
For additional commands: <ma...@jakarta.apache.org>
Troubles with the list: <ma...@jakarta.apache.org>
Re: Client-Cert authentication with Tomcat 4
Posted by Timothy Fisher <tr...@yahoo.com>.
You will get prompted for your password by the browser
when using client-cert authentication. The password
is necessary to unlock your private key.
Tim
--- Antony Bowesman <ad...@teamware.com> wrote:
> Hi,
>
> I have followed the comments in server.xml to get
> SSL working and have
> set up the security example to have client-cert as
> the auth method in
> web.xml. When I first connect to my host, the
> browser asks which
> certificate I want to send. However, the browser
> then prompts me for a
> username/password (as in basic authentication) when
> I try to connect to
> the protected page.
>
> I am using my own realm, however, from the Realm
> code, it seems that
> none of the realm implementations (including my own)
> implement the
> abstract getPrincipal)() method in RealmBase.java,
> i.e. they all return
> null so it seems that this will never work with the
> supplied realms.
>
> Am I missing something, does anyone have this
> working?
>
> Rgds
> --
> Antony Bowesman
> Teamware Group
> adb@teamware.com
> phone: +358 9 5128 2562
> fax : +358 9 5128 2705
>
> intra / extra / Internet solutions at
> www.teamware.com
>
> --
> To unsubscribe:
> <ma...@jakarta.apache.org>
> For additional commands:
> <ma...@jakarta.apache.org>
> Troubles with the list:
> <ma...@jakarta.apache.org>
>
__________________________________________________
Do You Yahoo!?
Find a job, post your resume.
http://careers.yahoo.com
--
To unsubscribe: <ma...@jakarta.apache.org>
For additional commands: <ma...@jakarta.apache.org>
Troubles with the list: <ma...@jakarta.apache.org>