Re: [security-dev] PicketLink restructure

Ok, let me lay it all out in a way that hopefully makes some more sense ;) In reviewing all of our various security offerings, it became quickly apparent to me that a new developer looking at our stuff would most likely become quickly confused - in fact there was even quite a bit of confusion during our recent Elluminate call as to which security modules did what. After Anil and I had a discussion about this we agreed that the first steps in reducing this confusion would be to re-purpose PicketLink as the "go to" project for security for Java EE developers. This greatly simplifies our message and gives us a single place to which we direct people who are looking for a security solution for their projects. PicketLink will be where we can point previous users of Seam Security to, and will compete head to head with other well-known "complete" security frameworks. In terms of Java SE, the only requirements I am aware of are those of the AS team wishing to use the IDM libraries - to this end we've maintained IDM as a submodule of PicketLink, without any CDI dependency. For a typical EE developer who just wants to get started, we simply tell them to add picketlink-core to their Maven dependencies which gives them everything. Just to be clear about what's in picketlink-core, it's simply the user session state management (i.e. the Identity bean), authentication API (which is based on CDI), CDI-enabled configuration for IDM, and the ACL Permissions API (built on DeltaSpike's security binding types). All of this is quite CDI-specific (except for the permissions stuff which could theoretically be rewritten as JavaSE however I have no interest in doing so). I can understand how at first glance it might seem weird that some modules are targetted at SE while core is EE, however it's my opinion that we shouldn't be pushing PicketLink as a set of "modules" anyway. The separation of the IDM module is only for the AS team's benefit, otherwise this feature would be part of core itself. In fact, I think we should downplay that it even consists of multiple modules. Remember, this is just the first step towards unifying our security message. We've still got a lot of work to do, including further discussions about what we do with PicketBox, which I hope we address in the coming weeks. Hopefully this has been helpful in shedding some light on the motivations for this restructure. Shane On 03/10/12 00:08, Pete Muir wrote: