shiro-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Les Hazlewood <lhazlew...@apache.org>
Subject Re: X509Certificate support
Date Fri, 11 Jun 2010 21:51:56 GMT
Just some quick notes:

The policy so far has been (and I think we should keep it this way)
that core has only 2 dependencies:  slf4j-api.jar for logging and
commons-beanutils for INI config, and that's it.   Commons beanutils
isn't even really a dependency if you don't use INI config.

Any other 3rd-party dependency is relegated to a support module.  In
fact, it could be argued that we should move the commons-beanutils
dependency into its own module at some point (or refactored to do our
own reflection and not depend on beanutils, but that could be a lot of
unnecessary work).

HTH,

Les

On Mon, May 24, 2010 at 10:23 AM, Brian Demers <brian.demers@gmail.com> wrote:
> Also,  After taking a very quick look at the patch.
>
> This requires a dependency on bouncycastle ( sort of the obvious choice ).
>  But this means the core will depend on bouncycastle.
>
> Les, what is the _policy_ for this type of dependency,   I don't think it
> should be a core dep.
>
> A couple of options are:
> 1.) Push this realm to its own sub-module.
> 2.) Mark the dep as optional/provided/etc ( not a big fan of this one )
> 3.) Nothing, leave it as a dep
>
>
> On Mon, May 24, 2010 at 1:11 PM, Brian Demers <brian.demers@gmail.com>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 <eskatos@n0pe.org> wrote:
>>
>>> Le lundi 24 mai 2010 18:26:39, Brian Demers a écrit :
>>> > Here is what we have:
>>> >
>>> http://github.com/sonatype/security/tree/master/security-realms/security-pu
>>> > 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
>>>
>>>
>>>
>>
>

Mime
View raw message