Mailing-List: contact shiro-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: shiro-dev@incubator.apache.org
Received-SPF: neutral (nike.apache.org: local policy)
MIME-Version: 1.0
Sender: les.hazlewood@anjinllc.com
In-Reply-To: <201005051204.05981.eskatos@n0pe.org>
References: <201005051204.05981.eskatos@n0pe.org>
Date: Wed, 5 May 2010 14:59:38 -0700
Message-ID: <q2g44b57a611005051459id0d88fc7sb0f4efe1a1ec5434@mail.gmail.com>
Subject: Re: X509Certificate support
From: Les Hazlewood <lhazlewood@apache.org>
To: shiro-dev@incubator.apache.org
Content-Type: text/plain; charset=UTF-8

Hi Paul,

First let me say that this is really cool - thanks so much for
considering to contribute!

As far as the deliverable - any way you want to do it is perfectly
fine.  My personal opinion is that it is actually easier to work with
a patch (even if it is kind of big) rather than a separate project.  A
separate project would require us to manually move code from one
project to another, whereas if it is a patch applied to the existing
codebase, we can rely on our IDEs to refactor and move stuff around.

I'd probably just create a new package like org.apache.shiro.x509 or
something like that, and then we can move those classes into
respective packages later if that makes sense.

But of course, we'd appreciate the submission in any form that makes
it easy for you to do so.  The best way to submit whatever deliverable
that you choose is attach it to a Jira issue.  That qualifies it as a
valid ASF contribution.  But if you think you might be working on this
stuff a little more regularly, you'll want to ensure that the ASF has
a CLA (Contributor License Agreement) on file.  Otherwise the
attachment will be fine!

Anyway, I'm looking forward to it!

- Les

On Wed, May 5, 2010 at 3:04 AM, Paul Merlin <eskatos@n0pe.org> wrote:
> Hi,
>
> For my own needs I wrote support of X509Certificate mutual authentication for
> shiro and I will contribute it back.
>
> I implemented several CredentialMatchers :
> - DN matching (but I think this is the poor's man mutual authentication as it
> opens security vulnerabilities)
> - certificate fingerprint matching (more robust IMHO)
> - full PKIX path validation using a trusted certificates collection provided by
> the underling realm (really nice if you have several authorities and a complex
> security model)
>
> All theses are working fine.
>
> Obviously some code in my current implementation is a bit specific but I think
> that with some more work it will be usable as a generic implementation.
>
> All this needs several classes, so I think about extracting the code from my
> project, packaging it as a standalone project depending on shiro so that it's
> easily testable without applying a complex patch. Les, do you have any
> suggestions about this ?
>
> Cheers
>
> /Paul
>
>
>