[Pki-devel] Client Authentication

[Ade Lee]

On Thu, 2011-10-27 at 18:33 -0700, Jack Magne wrote:
> Adam Young wrote: 
> > Ade,
> > 
> > Your ealier emali discussed the renegotiation challenge based on the
> > Profiles.  
> > 
> > http://pki.fedoraproject.org/wiki/REST#Profiles
> > 
> > For the case where a user points a browser (say and Ajax request)
> > at /pki/profiles   lets say that we have two cases:  one where the
> > user is authenticated and one where they are not.  In both cases,
> > they get back a collection, but in the case of unauthenticated it
> > will have significantly fewer entries.  
> > 
> > In this case, we would want the Java  equivalent of mod_nss:  
> > 
> > NSS_VerifyCLient: Optional
> > 
> > I'm guessing this a tomcatjss setting.
>  clientAuth="want"
> 
> For tomcatjss in server.xml
> 
> The thing is though, the way this behaves is the user is asked for the
> cert every time. The server then lets it go if the user choses not to
> send one, or uses it if they do.

Which is precisely the point, Adam.  We do not want end users to be
prompted for a certificate when they do not need to be.

In the UI, that will most likely be seen as a regression.

> > 
> > In this case, if the user has the certificate, they can present it,
> > but if they don't,  the operation will complete.  I think this is
> > what we want.  We always ask for the certificate, but we say it is
> > OK if you don't have it, you just don't get the data.
> > 
> > In the case where the user is asking for an object, say an actual
> > profile, and they don't have sufficient privs,  they get back a hard
> > and fast error:  probably 403.2 
> > 
> > http://en.wikipedia.org/wiki/HTTP_403
> > 
> > For something like CSRs, we probably want to restrict access to
> > agents.  In that case, if an unauthenticated user, or one without
> > appropriate privs,  attempts to access that URL,  they also get a
> > 403.2.
> > 
> > I don't know how this works in with the renegotiate, but I am
> > guessing that every time the user without a certificate hits an
> > "Optional" page they will be asked for their cert.  This might be
> > chatty.  No idea.
> > 
> > So in general,  we tag the URLS either 
> > NSS_VerifyClient: Require  if they must be authenticated to use them
> > NSS_VerifyClient: Optional  if they see different results based on
> > authentication or not
> > NSS_VerifyClient: None if they can view them unauthenticated and see
> > the same results as everyone else
> > 
> > 
> > IN the pki/WEB-INF/web.xml,  this probably maps to something like
> > this:
> > <security-constraint> 
> >    <web-resource-collection>
> >      <web-resource-name>Protected Resource</web-resource-name>
> >      <url-pattern>/*/profile</url-pattern>
> >    </web-resource-collection>
> >   
> > <auth-constraint>
> >          <role-name>anonymous</role-name>
> >          <role-name>agent</role-name>
> >    </auth-constraint>
> >   </security-constraint>
> > 
> > I'm guessing that we want to specify a role for anonymous as opposed
> > to no role.  
> > 
> > <web-app>
> > ...
> > 
> > <login-config>
> >  <auth-method>CLIENT-CERT</auth-method>
> >    <realm-name>Tomcat Manager Application</realm-name>
> >    <realm-name>PKICA</realm-name>
> >   </login-config>
> > ...
> > </web-app>
> > 
> > 
> > the PKICA  Realm would be defined at the server level, in
> > conf/server.xml.  Something like:
> > 
> > 
> > 
> > <Realm   className="com.netscape.catalina.realm.LDAPCertRealm"
> >      connectionURL="ldaps://localhost:8389"
> >        userPattern="uid={0},ou=people,dc=mycompany,dc=com"
> >           roleBase="ou=groups,dc=mycompany,dc=com"
> >           roleName="cn"
> >         roleSearch="(uniqueMember={0})"
> > />
> >   
> > There is a class  that almost does what we want.
> > 
> >  org.apache.catalina.realm.JNDIRealm.  
> > 
> > I suspect we can subclass it.  It has two ways of doing the auth :
> > Bind mode and Comparison mode.  It might be possible to add a
> > Client Cert mode in a subclass.  docs are here:
> > http://tomcat.apache.org/tomcat-6.0-doc/realm-howto.html#JNDIRealm
> > 
> > 
> > 
> > 
> > 
> > ____________________________________________________________________
> > 
> > _______________________________________________
> > Pki-devel mailing list
> > Pki-devel at redhat.com
> > https://www.redhat.com/mailman/listinfo/pki-devel
> >   
>