[aerogear-dev] Security Scaffolding

Matthias Wessendorf matzew at apache.org
Mon Apr 15 11:42:58 EDT 2013


sounds like a nice idea, to add this to our scaffolding; Would safe a lot
of time, when starting with a "backend / service" like that;

Pretty cool!




On Mon, Apr 15, 2013 at 2:38 PM, Bruno Oliveira <bruno at abstractj.org> wrote:

> On Monday, April 15, 2013 at 9:27 AM, Sebastien Blanc wrote:
> >
> >
> >
> > On Mon, Apr 15, 2013 at 2:05 PM, Bruno Oliveira <bruno at abstractj.org(mailto:
> bruno at abstractj.org)> wrote:
> > > Hi Sebi, I think this is a good idea, here comes few suggestion:
> > >
> > > * Replace create* for the entity only, into a scaffolding domain we
> assume that the user is willing to generate ALL the things. So for example:
> { "security": "users" :["sebi","abtractj"], //1 "role" :["simple","admin"],
> //2 "roleMap"
> > You mean creating users/role just for a particular entity ? Sorry I
> think I did not understand well this remark.
>
> Keep the same concept, only renaming the attributes like 'createUsers' to
> 'users'. (Create is something implicit). Makes sense?
> >
> > > * generateLoginForm and generateOTPPage. I'd replace by otp: true,
> login: true. Why? In our scenario doesn't exist jsp pages only, but also
> endpoints for it. I'm not specialist in this scaffolding topic, but my idea
> is: if the user specify true generate pages & endpoints, if they don't want
> jsp pages, just delete it.
> >
> >
> > Right, I have this idea just after sending the email, one thing should
> be "loginForm":"otp"|"classic"
> Maybe "login":"otp"|"default"
> >
> > >
> > > * Would be nice if we could provide an alternative to specify
> something more general for authentication/authorization, for example
> (ignore my poor scaffolding skills):
> > >
> > > https://gist.github.com/abstractj/ed6676b3106929cc23b0. And something
> which allows me to specify the exception, for example: "I want all of my
> endpoints requiring authentication, except the login endpoint.
> >
> > +1, invert the config, let me think on how we could define this in a
> clear way
> > >
> > > * You probably know about it, but just a reminder. Don't forget about
> configuration files from PicketLink (this would be something nice to be
> scaffolded). Maybe allow devs to specify persistence provider or database?
> For example: I want to use PicketLink with MySQL.
> >
> > +1, you could help me on this by providing me a complete list on the
> values and the locations that we could change, this way I can integrate it
> to the config.
> Here comes the config file commented my friend
> https://gist.github.com/abstractj/53ce0a9faae482151da2
> >
> > >
> > > Overall looks good.
> > Abstractj++ for the feedback !!
> > >
> > > --
> > > "The measure of a man is what he does with power" - Plato
> > > -
> > > @abstractj
> > > -
> > > Volenti Nihil Difficile
> > >
> > >
> > >
> > > On Monday, April 15, 2013 at 6:35 AM, Sebastien Blanc wrote:
> > >
> > > > Good Morning !
> > > > I've been thinking about Security Scaffolding. It's a different
> beast than a simple CRUD scaffolding. It'sa bit more difficult to make
> assumption when you want to generate security flows : which http method to
> protect ? using only authentification or also authorization ? etc ...
> > > >
> > > > Therefore, I've been thinking of some kind of configuration that the
> user could provide before the scaffolding process. Keeping it really simple
> and "human readable" and that could really speed up setting up the security
> layer :
> > > >
> > > >
> > > > { "security": "createUsers" :["sebi","abtractj"], //1 "createRole"
> :["simple","admin"], //2 "roleMap":
> ["simple":["abstractj","sebi"],"admin":["sebi"]], //3 "generateLoginForm" :
> true, //4 "generateOTPPage" : true, //5 "entities" : { //6 "org.sebi.Task"
> : { "GET": { "authentification" : false }, "POST": { "authentification" :
> true, "authorization" : "simple" }, "PUT": { "authentification" : true,
> "authorization" : "admin" }, "DELETE": { "authentification" : true,
> "authorization" : "admin" } } } }
> > > >
> > > > Let me detail each of these points to make the discussion easier :
> > > >
> > > > * 1. createUSers : We pass a list of users that we be inserted into
> the db : this will generate or a SQL script or a class creating the users
> like in
> https://github.com/aerogear/aerogear-controller-demo/blob/master/src/main/java/org/jboss/aerogear/controller/demo/config/PicketLinkDefaultUsers.java
> > > > (
> https://github.com/aerogear/aerogear-controller-demo/blob/master/src/main/java/org/jboss/aerogear/controller/demo/config/PicketLinkDefaultUsers.java
> )
> > > >
> > > > * 2. createAdmin : We pass a list of roles that we be inserted into
> the db : this will generate or a SQL script or a class creating the users
> like in
> https://github.com/aerogear/aerogear-controller-demo/blob/master/src/main/java/org/jboss/aerogear/controller/demo/config/PicketLinkDefaultUsers.java
> > > >
> > > > * 3. roleMap : We create here an association map between users and
> roles : this will generate or a SQL script or a class creating the users
> like in
> https://github.com/aerogear/aerogear-controller-demo/blob/master/src/main/java/org/jboss/aerogear/controller/demo/config/PicketLinkDefaultUsers.java
> > > >
> > > > (
> https://github.com/aerogear/aerogear-controller-demo/blob/master/src/main/java/org/jboss/aerogear/controller/demo/config/PicketLinkDefaultUsers.java
> )
> > > > * 4. generateLoginForm : if true, the UI scaffolding will also
> generate a login form (location and layout depending on the scaffolding
> provider (AngularJS+Bootstrap, AngularJS+JQM) or by providing a custom
> template fragment.
> > > >
> > > > * 5. generateOTPPage : if true, the UI scaffolding will also
> generate a OTP page (location and layout depending on the scaffolding
> provider (AngularJS+Bootstrap, AngularJS+JQM) or by providing a custom
> template fragment.
> > > >
> > > > * 6. Entities : Here we configure the security flow for each entity
> per HTTP methods. Concretely, this will mean :
> > > > - On the backend, generate the right route, i.e :
> > > >
> route().from("/task").roles("admin").on(RequestMethod.DELETE).to(Task.class).delete();
> > > >
> > > > - On the frontend, setting the flag or not on a pipe to enable auth.
> Other option are possible, liking hiding links, disabling button depending
> on the authorization/authnetification. We should discuss these options.
> > > >
> > > > I think it could be a nice addition, and from the feedback I've
> heard, this kind of feature really misses today in the current scaffolding
> tools regarding security. This could be really a killing feature and not
> hard to implement.
> > > >
> > > > Please comment, ask questions to polish the feature !
> > > >
> > > > Seb
> > > >
> > > >
> > > > _______________________________________________
> > > > aerogear-dev mailing list
> > > > aerogear-dev at lists.jboss.org (mailto:aerogear-dev at lists.jboss.org)
> (mailto:aerogear-dev at lists.jboss.org)
> > > > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> > >
> > >
> > >
> > >
> > > _______________________________________________
> > > aerogear-dev mailing list
> > > aerogear-dev at lists.jboss.org (mailto:aerogear-dev at lists.jboss.org)
> > > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> >
> >
> > _______________________________________________
> > aerogear-dev mailing list
> > aerogear-dev at lists.jboss.org (mailto:aerogear-dev at lists.jboss.org)
> > https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
>
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>



-- 
Matthias Wessendorf

blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20130415/79ed2bee/attachment-0001.html 


More information about the aerogear-dev mailing list