12:23 p.m.
On 4 Oct 2012, at 08:59, Anil Saldhana wrote:
On 10/03/2012 05:50 PM, Shane Bryzak wrote:
> On 04/10/12 01:20, Anil Saldhana wrote:
>> On 10/03/2012 10:17 AM, Pete Muir wrote:
>>> On 3 Oct 2012, at 08:10, Anil Saldhana wrote:
>>>
>>>> On 10/01/2012 07:00 PM, Pete Muir wrote:
>>>>> It seems odd to me that CDI is called core? I thought the idea was
that picketlink core would be pure Java SE, and CDI support gets added on top.
>>>>>
>>>>> But +1 to the merge. The more we can put under one project, with one
brand the better.
>>>>>
>>>>> I talked to Anil about merging PicketBox into PicketLink as well, as
"just another module" and I think this will make things a lot simple for users
to understand.
>>>> Pete, lets wait for PL codebase to stabilize before figuring out
>>>> PicketBox.
>>> :-) Yes, we don't need to do this now, just throwing around ideas.
>>>
>>>> As I said, from JDF perspective and pitching to application
>>>> developers, it makes sense to go with PL. But for framework writers and
>>>> folks dealing with AS security and stuff, they have to do PBox.
>>> Still not sure why that means we can't do it like the IDM - as a pure
Java SE submodule of PicketLink. This to me is more about brand simplicity than anything.
>> PicketBox has lots of stuff. Container Security plus xacml and other
>> things which need to be properly migrated/massaged/discarded/eased into
>> our final offering. We don't want to make PL a bloated security offering.
> +1, I'm dubious of the value of adding PicketBox as a module, especially
> as it's based on the old JavaEE Principal/Subject security model which
> we've totally moved away from now. Perhaps some of the features such as
> XACML could be implemented as a standalone module (if it isn't already)
> in PicketBox and then we provide some integration code for that. I
> wouldn't think though that XACML is an overly popular feature anyway,
> especially since we'll be providing Drools-based permissions in PL already.
Actually the JavaEE principal/subject model in PicketBox is what is
termed PicketBox Legacy in the following diagram:
https://docs.jboss.org/author/display/SECURITY/SecurityProjectsArchitecture
Before moving your security work from Apache Deltaspike to PicketLink,
we were already in the works to provide security for applications in
JavaSE environment.
https://docs.jboss.org/author/display/SECURITY/Java+Application+Security
These projects are all housed at:
https://github.com/picketbox
Some of them such as picketbox-cdi, picketbox-deltaspike and
picketbox-solder need to nuked but the other projects are all valuable
code in JavaSE environments.
I'm *definitely not* saying that PicketBox is not valuable, in fact I'm really
saying it's very valuable, and that as such it should be part of our security brand
"PicketLink".
As things like Fabric/JBoss Everywhere come more into the picture, then Java SE is going
to become more and more important.
I think it was Lincoln who said "for PicketLink, let's start with Java SE, get a
really solid core, and then go from there to Java EE".
>
>
>>>>> On 1 Oct 2012, at 15:30, Shane Bryzak wrote:
>>>>>
>>>>>> In the interests of presenting a clear message to our developers,
one of the steps we'll be taking is to consolidate the various PicketLink projects
into a single project and presenting this as the "go to" solution for
application security. For now I've merged the CDI and IDM subprojects (these are now
submodules of the PicketLink project, with "CDI" renamed to "Core")
and the plan is to eventually merge the social and federation modules also.
>>>>>>
>>>>>> You can find the new GitHub repository here:
https://github.com/picketlink (renamed from picketlink-cdi) and the picketlink-idm
repository has now been deleted. For anyone working on these modules, please use the new
repository from now on.
>>>>>>
>>>>>> Thanks!
>>>>>> Shane
>>>>>>
>>>>>>
_______________________________________________
security-dev mailing list
security-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/security-dev