[security-dev] Securing TicketMonster with PicketBox Core

[Marius Bogoevici]

On 2012-07-27, at 1:02 PM, Pete Muir <pmuir at redhat.com> wrote:

> Agreed, there is lots to like here :-)
> 
> Initial thoughts:
> 
> * Need to simplify drools setup (but not complaining, as I know this is WIP :-)
> * We should wrap the authentication API and configuration you are using with DeltaSpike authentication. This should tidy up the configuration a lot I think. Let's discuss this in a separate thread
> * Drop the requirement to use a JEE complaint authentication form. These things are a nightmare. Instead, we need to authenticate the user via JAAS using the DS authentication API. This then means we can use any form we like in the front end.
> * As Marius alludes to, it would be nice to be able to secure REST endpoints using DeltaSpikes security bindings. We could add a binding type that will defer to Drools. Advantantage of this is that we can the get a context about the invocation.
> 
> On 27 Jul 2012, at 17:25, Anil Saldhana wrote:
> 
>> On 07/27/2012 11:20 AM, Marius Bogoevici wrote:
>>> Hi Anil,
>>> 
>>> This looks like a great start. I see that there are quite a few TODO items on the list.
>>> 
>>> Any timeline on them?
>> We are working on a lot of things with PicketBox.  So we will tackle 
>> these TODOs one by one with very short implementation cycles. If you are 
>> able to prioritize the todos, it will be helpful.
> 
> 1) Replacing login form with method based authentication tied into JAAS (Seam 2 did this if you want inspiration)
> 2) Switching away from Solder, as it is EOL
> 3) Use DS authentication API
> 4) Introduce cetralised URL security
> 5) Introduce SPA login
> 6) Logout
> 7) secure REST endpoints
> 8) JSON security
> 9) IDM integration
> 10) Fine grained permissions / role based permissions
> 11) Remember me
> 12) Introduce a security binding type that is Drools specific and can reference rules

+1

> 
>>> 
>>> Here's  thought. I think AJAX security can be split into either:
>>> 
>>> a) REST endpoint security (which goes back to securing the REST endpoint classes)
>> PicketBox core will have implementations of JSON Security. I am unsure 
>> DS is planning on that.  IMO all REST based interactions are either atom 
>> or JSON.  What I have seen is json is used in almost all the use cases.
> 
> It's not planning anything here. Actually Marius is just talking about restricting access to REST endpoints, probably using an annotation on the endpoint.
> 
>> 
>>> b) URL security
>>> 
>>> Now for the former, I think we should use the DeltaSpike @Secured facilities (I don't know exactly in what state they are right now, as existing stuff is interspersed with roadmap stuff in my head right now).
>>> 
>>> Marius
>>> 
>>> 
>>> On 2012-07-27, at 11:29 AM, Anil Saldhana <Anil.Saldhana at redhat.com> wrote:
>>> 
>>>> https://docs.jboss.org/author/display/SECURITY/TicketMonster
>>>> 
>>>> We can discuss about it here.
>> _______________________________________________
>> security-dev mailing list
>> security-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/security-dev
> 
> 
> _______________________________________________
> security-dev mailing list
> security-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/security-dev