Reg: Dynamic Role Management

[deepu ks]

Hi Guys,

I need opinion from you guys on this. 

For this issue I have implemented Dynamic role management with control at the Resource method level and a nice GUI to create Roles and assign permissions. 

Now this can be part of the main generator to replace the current hard coded ROLE management or I can make it a module (With some nasty hacks). My personal preference is to have it in the main generator with the role management screens under admin as it would be easier to maintain and would be more useful.

The current behavior can be retained as is with current ROLES and their resource permissions pre configured. Users can add their own roles and change which modules each role can access from the GUI

Here is a repo with a sample application with this. Check the Role Management page under Admin.

The concept is to assign view/create/edit/delete permission to a Resource. There is a constant file called ResourcesConstant which will hold all resource names, during entity creation the resource name for the entity will be added to this file. On the Java Resource class the same will be checked dynamically based on the logged in users role using @PreAuthorize("@jhiAuth.hasPermission('USER_RESOURCE', 'CREATE')") check UserResource for a sample implementation. The CustomPermissionEvaluatorService class takes care of evaluating permission for roles to access resources. Please note that this is not ACL, This is just our current Authorization mechanism with ability to customize Role permissions dynamically which is hard coded currently.

On the client side this would require adding the Resource name in the states instead of the authorities which we do currently. I haven't done that part yet but that straightforward.

Im using this approach in production for very complicated role management and is running without issues so far.

Implementation is not complete yet but I wanted to get your feedback before proceeding to polish and template this.

Thanks & Regards,

Deepu

[Christophe Bornet]

My concern is that on one of my project, I disable security completely by just configuring the security class. I fear that it would be harder if I need to edit every resource class...

--
You received this message because you are subscribed to the Google Groups "JHipster dev team" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jhipster-dev...@googlegroups.com.
To post to this group, send email to jhipst...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jhipster-dev/CAFXry55FtT056_XSAdMAkhLcRdiok33cY4yzCZvfUGuXOJqiLg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[deepu ks]

You can still disable it by editing only the customPermissionEvaluater to return true always

Thanks & Regards,

Deepu

To view this discussion on the web visit https://groups.google.com/d/msgid/jhipster-dev/CAE8RvoV4uy6Obz0gzmgnuJTdZ4tVPVL8zmZUYQAU1Yf3F0LgNg%40mail.gmail.com.

[deepu ks]

Hi Guys,

Im waiting to hear your opinions. Especially yours Julien.

Thanks & Regards,

Deepu

[Thibaut Mottet]

Hey deepu,

That a big work!! I like the way you implement the functionality!

This is my feedback:

- If it’s in the main generator, I think it will be better to add a new question with the old way by default. It’s possible to manage both approach in the generator?

- In my current project I have more than 50 entities and more than 6 roles, with your experience it will not complicated to manage everything?

Like always, you work toooooo much!!! :)

Thibaut.

To view this discussion on the web visit https://groups.google.com/d/msgid/jhipster-dev/CAFXry54A7v-u6i3CiW44eoNZuT2-GX5baJ8iXTzW1HcbkLKK%3DQ%40mail.gmail.com.

[deepu ks]

Thibaut,

I guess it can be a question with both approach, wont be very different to manage

I used the same technique on 2 apps so far one with 100+ entities and around 40 roles already, users are adding more roles as required themselves. SO I dont think there is any issue as its all generated during entity creation and user just needs manage roles through a UI as required.

Thanks & Regards,

Deepu

To view this discussion on the web visit https://groups.google.com/d/msgid/jhipster-dev/7AE772A2-2612-4B74-9FD8-68D45168DED5%40gmail.com.

[Julien Dubois]

Hi Deepu,

I have a training finishing tomorrow, I will take a look afterwards.

Pierre & William are probably going to use it on an internal project at Ippon, I need to check with them, but I know they already had a look.

Then I guess you have quite a lot of code: I'm not sure this should be generated, shouldn't we have an external JAR for that? We don't have this yet, but we could have specific JHipster librairies.

Julien

--

Julien Dubois

Twitter: @juliendubois
Phone: +33 (0)6 25 02 34 18

[deepu ks]

Its not a lot of code actually. The authorization is done at just one java class remaining is just a module like user management so if we can make user management a lib then we can make tole management a lib as well, but then people wont be able to customise it further

To view this discussion on the web visit https://groups.google.com/d/msgid/jhipster-dev/CADNXADEH2dqkjQDqRKCi3pdvejMYhA_Tc%3DvXpyD-4xa0mOZ0rQ%40mail.gmail.com.

[Christophe Bornet]

OK. Great !

On Saturday, April 23, 2016 at 4:11:50 AM UTC+2, deepu ks wrote:

You can still disable it by editing only the customPermissionEvaluater to return true always

Thanks & Regards,

Deepu

On Sat, Apr 23, 2016 at 3:07 AM, Christophe Bornet <bornet...@gmail.com> wrote:

My concern is that on one of my project, I disable security completely by just configuring the security class. I fear that it would be harder if I need to edit every resource class...

Le 22 avr. 2016 06:46, "deepu ks" <deepu...@gmail.com> a écrit :

Hi Guys,

I need opinion from you guys on this. 

For this issue I have implemented Dynamic role management with control at the Resource method level and a nice GUI to create Roles and assign permissions. 

Now this can be part of the main generator to replace the current hard coded ROLE management or I can make it a module (With some nasty hacks). My personal preference is to have it in the main generator with the role management screens under admin as it would be easier to maintain and would be more useful.

The current behavior can be retained as is with current ROLES and their resource permissions pre configured. Users can add their own roles and change which modules each role can access from the GUI

Here is a repo with a sample application with this. Check the Role Management page under Admin.

The concept is to assign view/create/edit/delete permission to a Resource. There is a constant file called ResourcesConstant which will hold all resource names, during entity creation the resource name for the entity will be added to this file. On the Java Resource class the same will be checked dynamically based on the logged in users role using @PreAuthorize("@jhiAuth.hasPermission('USER_RESOURCE', 'CREATE')") check UserResource for a sample implementation. The CustomPermissionEvaluatorService class takes care of evaluating permission for roles to access resources. Please note that this is not ACL, This is just our current Authorization mechanism with ability to customize Role permissions dynamically which is hard coded currently.

On the client side this would require adding the Resource name in the states instead of the authorities which we do currently. I haven't done that part yet but that straightforward.

Im using this approach in production for very complicated role management and is running without issues so far.

Implementation is not complete yet but I wanted to get your feedback before proceeding to polish and template this.

Thanks & Regards,

Deepu

--
You received this message because you are subscribed to the Google Groups "JHipster dev team" group.

To unsubscribe from this group and stop receiving emails from it, send an email to jhipster-dev+unsubscribe@googlegroups.com.

To post to this group, send email to jhipst...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jhipster-dev/CAFXry55FtT056_XSAdMAkhLcRdiok33cY4yzCZvfUGuXOJqiLg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "JHipster dev team" group.

To unsubscribe from this group and stop receiving emails from it, send an email to jhipster-dev+unsubscribe@googlegroups.com.