[security-dev] PicketLink workspace proposal

Anil Saldhana Anil.Saldhana at redhat.com
Mon Oct 8 11:38:48 EDT 2012


On 10/04/2012 01:37 PM, Pete Muir wrote:
> On 4 Oct 2012, at 10:48, Bruno Oliveira wrote:
>
>> On Thursday, October 4, 2012 at 12:24 PM, Anil Saldhana wrote:
>>> Hi all,
>>> here is what Shane and I have been discussing in the last 10 days
>>> that we can come to an agreement in this thread. Please provide your
>>> feedback and insights as we move forward with the PicketLink main workspace.
>>>
>>> Proposal:
>>> PicketLink main workspace will have the following modules:
>>> a) core : will contain the CDI based security code that Shane has been
>>> driving.
>> Maybe as already suggested, split into core and CDI, could be a good idea.
> And if PicketBox is really the "core", then perhaps that becomes PicketBox core?
Right - from application developer perspective, using CDI and its 
associated security makes perfect sense.  That is why the PL module 
needs to be called CDI.  But for many framework developers (such as in 
AS and other JBoss Community projects) that do not want to have CDI 
dependency but regular SE based security, then PicketBox core is the 
right answer.

>
>>> b) idm: will contain the idm api and impl submodules. This is low
>>> dependency JavaSE library for Identity Management functionality (CRUD of
>>> users/roles/groups). This module is ultra critical to all projects. c) federation: will contain the core SAML (and maybe WS-Trust) code
>>> c) federation: will contain the core SAML (and maybe WS-Trust) code
>>> without any EE container dependencies. Mainly parsing, writing and model
>>> code.
>>> d) social: will contain social login code that allows signin using
>>> facebook, google/openid, twitter.
>> +1
>>> Versioning:
>>> Last major release of PL has been with 2.1.5
>>> (https://docs.jboss.org/author/display/PLINK/v2.1.5.Final)
>>> So definitely we can release above with 3.x
>>>
>>> Since we may need some container binding code with AS, Tomcat etc, we
>>> have two possibilities:
>>> a) Create another workspace in PicketLink github organization for the
>>> container binding. (My preference)
>> +1
>>> b) Create a separate github organization that will host all the
>>> container bindings, integration testing workspaces etc. We can call it
>>> picketlinkbindings.
>> -1
>>> Regards,
>>> Anil


More information about the security-dev mailing list