Re: [security-dev] Securing TicketMonster with PicketBox Core

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

>> >> 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(a)redhat.com&gt; wrote: >> >>> https://docs.jboss.org/author/display/SECURITY/TicketMonster >>> >>> We can discuss about it here. > _______________________________________________ > security-dev mailing list > security-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/security-dev _______________________________________________ security-dev mailing list security-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/security-dev