shiro-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Demers <>
Subject Re: X509Certificate support
Date Sat, 12 Jun 2010 17:00:05 GMT
The public key realm we have is tailored for Apache Mina SSHD,  it is pretty
basic,just compares 2 public keys (and provides an interface for the storage
of the public keys)  With no other dependencies

We where planning on pushing the the auth bits back to Mina (if there was an
interest).  We have two parts, 1. a public key realm, and 2. Mina SSHD
session/authorization implementations that bridge to Shiro.

We where thinking about pushing the public key realm to Shiro, and the rest
to Mina.  Any thoughts on that?

Also, a note about external deps, it would be nice to include javax.inject,
( and use the @inject annotations in Shiro )  But I think that is a
different thread ;)

On Sat, Jun 12, 2010 at 5:14 AM, Paul Merlin <> wrote:

> My current patch is only about TLS mutual authentication.
> /Paul
> Le 12 juin 2010 à 03:59, Les Hazlewood <> a écrit :
>  Sorry, I forgot to clarify that my last post does not assume the use
>> of SSL.  An alternative, which I'm sure is what Paul was talking
>> about, is to use X.509 for TLS-based mutual authentication between a
>> web server and web browser.  Note that this can be very slow and a
>> huge resource hog for the web servers though.
>> <opinion>
>> It's OK for intranet apps, but most public facing webapps won't
>> support this due to the performance impact as well as one nasty little
>> issue:  it requires browser configuration and often end-user 'know
>> how' - most people are insanely confused by this stuff.
>> Even in intranet environments though, it is often better to support
>> things like One Time Passwords and two-factor authentication (FOBs,
>> smart cards, etc) because they don't require client-side configuration
>> (a potential burden for IT to maintain inside an organization) and can
>> even be used (easily) outside of the intranet (think of a remote
>> contractor using VPN into a company's dev network).
>> </opinion>
>> Nonetheless, if the community wants TLS-based X.509 support, we should
>> definitely support it.
>> Les
>> On Fri, Jun 11, 2010 at 5:42 PM, Les Hazlewood <>
>> wrote:
>>> Hi all,
>>> Comparing two public keys does not constitute a valid authentication.
>>> X.509 certificates (and the public keys within them) are expected to
>>> be publicly distributed, so their content alone should not be
>>> considered as a credential.
>>> I think I should write a blog article about how to do this effectively
>>> - the very short summary is that there are usually two common ways of
>>> doing X.509 authentication:
>>> 1.  Using the X.509 certificate alone (nothing else):  The server
>>> encrypts something (e.g. a random token) with the public key contained
>>> in the user's X.509 certificate.  That encrypted data is given to the
>>> user.  The user decrypts it with their private key (the one
>>> corresponding to their public key in the X.509 cert) and gives the
>>> decrypted data back to the server.  If the server receives the correct
>>> data, then it knows the identity is authentic since only that user's
>>> private key could have decrypted the token successfully.
>>> 2.  X.509 certificate and credentials: The user encrypts a credential
>>> (password, biometric signature, whatever) with their private key.  The
>>> server receives the encrypted credential and decrypts it with the
>>> public key in the X.509 certificate.  If the decrypted value matches
>>> the one stored in the system, the identity is considered authentic.
>>> HTH,
>>> Les
>>> On Mon, May 24, 2010 at 10:11 AM, Brian Demers <>
>>> wrote:
>>>> Yeah, the comparing of two public keys confused me (still does actually)
>>>> but
>>>> I emailed the apache sshd list of conformation (hasn't hit the archive
>>>> yet,
>>>> so no link)
>>>> Anyone else have any thoughts on these realms?
>>>> On Mon, May 24, 2010 at 12:56 PM, Paul Merlin <> wrote:
>>>>  Le lundi 24 mai 2010 18:26:39, Brian Demers a écrit :
>>>>>> Here is what we have:
>>>>>> blic-key-realm/
>>>>>> Note this just compare two public keys, ( so this assume something
>>>>>> else
>>>>> is
>>>>>> doing the hand shaking with the private key )
>>>>> Thanks for sharing Brian.
>>>>> Some things are similar to my implementation (already attached as a
>>>>> patch
>>>>> in
>>>>> jira). Looking at PublicKeyWithEquals, it could be related to my second
>>>>> matching
>>>>> strategy, fingerprint, except that you compare the public key data
>>>>> (pk.getEncoded()) and not the certificate data.
>>>>> Be aware that a KeyPair can be certified several times and so a
>>>>> PublicKey
>>>>> can be
>>>>> used in several X509Certificate 'instances'.
>>>>> IOW the ssl engine had the proof that the client own the PrivateKey and
>>>>> that
>>>>> it's certificate is trusted. You then match only the PublicKey that's
>>>>> inside the
>>>>> certificate, not the certificate itself.
>>>>> Use cases leading to a security hole in your implementation will
>>>>> certainly
>>>>> by
>>>>> awkward and depend a lot on deployment and certification policies but
>>>>> one
>>>>> can
>>>>> imagine such a scenario.
>>>>> We could say the very same about my Simple strategy.
>>>>> /Paul

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message