Generator-jhipster: Feature request: Dynamic Role Management

[deepu105]

I thought i'll wait for User Management to be released before opening this, but seems like its good to start discussion as there could be some tweaks in user management based on this.
There has been already some discussion on this here (https://github.com/jhipster/generator-jhipster/issues/1525) but I would like to start a fresh thread concentrating on this

Issue

Currently Jhipster has a role based access control implemented but it has the following short comings/limitations

• the ACL is hard coded (this is the major issue as any change in role access needs a system change which is not ideal in production)
• there is no method level or entity level security, current model provides either all or just entities based on URL
• current model is suitable only for simple use cases like a simple blog etc, its not suitable when you have lot of users with different access rights to different entities/section/modules
• current implementation is bit misleading as it actually does not do any permission check
• above all its difficult to maintain and lot of code to manage spread out here and there

Solution

This is a simplified version of what I have done for a customer in a JHipster app and it is working beautifully, but my use case was far more complex so I had it working in a similar fashion

• assign a unique resource name for each entity to begin with say BOOK_RESOURCE (users can further tweak this to have multiple section for a same entity if needed) this name can be generated during entity generation and updated in an enum or as a DB entry in a changelog at back end. The same can be put as a static variable in each Java Resource file and also updated into the route.js files
• have a role management module to create/edit roles like ROLE_ADMIN, ROLE_CUSTOMER etc
• In a role assign grant to resources, grant will be a numeric value from 0 to 4, each mapping to GET,POST,PUT and DELETE
  
  
  
  • 0 -> no grant
  
  
  • 1 -> view only
  
  
  • 2 -> view & create
  
  
  • 3 -> view, create & edit
  
  
  • 4 -> view, create, edit & delete
  
  
• persist this resource grant mapping in DB for the role/authority and assign the role to users in user management, now we know which user has what grant to each resource
• In an EntityResource class have all REST methods annotated with @Secured(RESOURCE_NAME)
• have a CustomAccessDecisionManager which checks the resource against users grant
• In JS do a similar check for the routes

and voila we have a completely controlled and dynamic access management
this also gives end users opportunity to further customize for their needs to obtain complex role access logic

So this is an idea, I'm definitely not a spring security expert so there might be better ways to do it, but if the dev board and community thinks that this solution is good i'll be happy to implement it in JHipster
@jdubois @gzsombor @atomfrede @andidev @gmarziou

It would be great to get opinion from the spring security guys as well @rwinch I would be grateful if you can comment on this approach

@phouverneyuff you had some ideas on this as well, plz feel free to comment

this kind of implementation can co exit with current model if required or can completely replace the current one or could be a question during generation

Sample

@RestController
@RequestMapping("/api")
public class BookResource {

    private final static String RESOURCE = "BOOK_RESOURCE";

    @RequestMapping(value = "/books",
            method = RequestMethod.POST,
            produces = MediaType.APPLICATION_JSON_VALUE)
    @Timed
    @Secured(RESOURCE)
    public ResponseEntity<Void> create(@RequestBody Book book) throws URISyntaxException {
        .....
    }

    @RequestMapping(value = "/books",
            method = RequestMethod.GET,
            produces = MediaType.APPLICATION_JSON_VALUE)
    @Timed
    @Secured(RESOURCE)
    public List<Book> getAll() {
        ...
    }

}

/**
 * Custom method security configuration
 */
@Configuration
@EnableGlobalMethodSecurity(prePostEnabled = true, securedEnabled = true, proxyTargetClass = true, mode = AdviceMode.PROXY)
public class MethodSecurityConfiguration extends GlobalMethodSecurityConfiguration {

    public AccessDecisionManager accessDecisionManager() {
        CustomAccessDecisionManager accessDecisionManager = new CustomAccessDecisionManager ();
        return accessDecisionManager;
    }
}

/**
 * Custom Access decision manager for method security
 */
public class CustomAccessDecisionManager implements AccessDecisionManager {

    private final Logger log = LoggerFactory.getLogger(CustomAccessDecisionManager.class);

    @Override
    public void decide(Authentication authentication, Object object, Collection<ConfigAttribute> configAttributes) throws AccessDeniedException, InsufficientAuthenticationException {
        ConfigAttribute configAttribute = SecurityUtils.getSingleConfigAttribute(configAttributes);

        MethodInvocation methodInvocation = (MethodInvocation) object;

        try {
            if(authentication != null) {
                User user = SecurityUtils.getCurrentUser(authentication);
                RequestMapping requestMapping = null;
                for (Annotation annotation : methodInvocation.getMethod().getDeclaredAnnotations()) {
                    if(annotation instanceof RequestMapping){
                        requestMapping = (RequestMapping) annotation;
                    }
                }

                String method = SecurityUtils.getHttpMethod(requestMapping);
                String resourceName = SecurityUtils.getResourceName(configAttribute);

                if (user != null && ! hasAccessToResource(user, method, resourceName)) {
                    throw new AccessDeniedException("User does not have enough privileges to access this method");
                }
            }
        } catch (ClassCastException e) {
            throw new IllegalStateException();
        }
    }


    @Override
    public boolean supports(ConfigAttribute attribute) {
        return false;
    }

    @Override
    public boolean supports(Class<?> clazz) {
        return clazz.equals(MethodInvocation.class);
    }
    /**
     * checks if the resource has grants in any roles for the user
     * @param user
     * @param method
     * @param resourceName
     * @return
     */
    private boolean hasAccessToResource(User user, String method, String resourceName) {
/*
*  The resources are converted into
*  a map while retrieving user for first time and later use the map to fetch the section and check access.
*/

        Map<String, ResourceDTO> validResources = user.getValidResources();
        if(validResources !=null && !validResources.isEmpty()) {
            ResourceDTO validResource = validResources.get(resourceName);
            if (validResource != null && hasGrants(validResource, method)) {
                log.debug("Role has access to resource:{} ", validResource);
                return true;
            }
        }
        return false;
    }


    /**
     * checks for grant for HTTP methods
     * GET = 1 = VIEW,
     * POST = 2 = CREATE,
     * PUT = 3 = EDIT,
     * DELETE = 4 = DELETE
     *
     * @param resource
     * @param method
     * @return
     */
    private boolean hasGrants(ResourceDTO resource, String method) {
        int grant = 0;
        switch (method){
            case "GET":
                grant = 1; break;
            case "POST":
                grant = 2; break;
            case "PUT":
                grant = 3; break;
            case "DELETE":
                grant = 4; break;
            default:
                grant = 0;
        }

        return resource.getGrant() >= grant;
    }

}

[mmaask]

I like the approach, did something similar on role level for my project, but I had additional layer where I had first to assign set of grants to an entity and users within that entity can have separate grants inherited from the entity itself.

In my experience in other projects though, this sort of 5 level granularity for grants is too much. Have always assumed that 'edit' grant would be all 'edit and create and delete' or 'edit and create' an 'delete' separately. It's hard to tell though, maybe it would suit here

What is the front-end solution you used for this?

[jdubois]

What's important to me is that we should have an excellent Spring Security integration, and there is still some work to do on this part (including the user management screen, but not only):

• Indeed, we should not go further until the user management screen is finished
• Besides, I'm not sure we need to go further

Let me explain:

• We do have method-level security, and even ACL, from Spring Security -> it's Spring Security's job to do all this, and it does it better than any other framework on the market. Have you seen http://docs.spring.io/spring-security/site/docs/3.0.x/reference/domain-acls.html ? I haven't used it for something like 10 years, and it has been refactored since, so I'm not an expert on this, but it does deserve a look as it's the "official way" and we don't have to do anything
• I have always found ACLs on entity instances were a bad idea. Besides, I've only seen a couple of projects which did implement those, and this was a big mess each time. For me, this is business logic, and it should be coded as such

Of course, if we can have insight from @rwinch it will be much appreciated, as I think it's the third time I see someone asking for this on JHipster.

[deepu105]

@jdubois im not suggesting ACL on individual entity instance here im
talking about giving a role create access for books and not at instance
level just at the method level, spring has method security but on Jhipster
there is no provision made to use those.
On 11 Sep 2015 15:18, "Julien Dubois" [email protected] wrote:

What's important to me is that we should have an excellent Spring Security
integration, and there is still some work to do on this part (including the
user management screen, but not only):

• Indeed, we should not go further until the user management screen is
  finished
• Besides, I'm not sure we need to go further

Let me explain:

• We do have method-level security, and even ACL, from Spring Security
  -> it's Spring Security's job to do all this, and it does it better than
  any other framework on the market. Have you seen
  http://docs.spring.io/spring-security/site/docs/3.0.x/reference/domain-acls.html
  ? I haven't used it for something like 10 years, and it has been refactored
  since, so I'm not an expert on this, but it does deserve a look as it's the
  "official way" and we don't have to do anything
• I have always found ACLs on entity instances were a bad idea.
  Besides, I've only seen a couple of projects which did implement those, and
  this was a big mess each time. For me, this is business logic, and it
  should be coded as such

Of course, if we can have insight from @rwinch https://github.com/rwinch
it will be much appreciated, as I think it's the third time I see someone
asking for this on JHipster.

—
Reply to this email directly or view it on GitHub
https://github.com/jhipster/generator-jhipster/issues/1995#issuecomment-139470641
.

[jdubois]

OK, it's at the entity level -> then it would be on the service layer. But I know, with Hibernate you can bypass the service layer very easily!

[deepu105]

It need not be at the service level if you can restrict at the controller
with get,post,put, delete verbs as it is easier to control, and trust me my
current role management logic is very very very complex. And i was able to
achieve it with this approach.
In my implementation I can restrict access based on various factors which
can be configured on a role like based on the company user belongs to,
based on users base station, based on a group user belongs to and even any
combination of these. But what i propose here is not that complex its just
create a role and say which resources can be accessed and with what kind of
grant so its making use of spring method security instead of hard coding
the access based on url in the SpringSecirityConfiguration

So if i create a role called library-admin i can say it has get for library
resource, put for book resource and delete for reader resource etc.

I guess not an ideal example but you get the idea right?

On Sat, 12 Sep 2015 2:43 pm Julien Dubois [email protected] wrote:

OK, it's at the entity level -> then it would be on the service layer. But
I know, with Hibernate you can bypass the service layer very easily!

—
Reply to this email directly or view it on GitHub
https://github.com/jhipster/generator-jhipster/issues/1995#issuecomment-139733446
.

[LiuXiaoJie]

Is there any update on this? Really think it is useful.

[deepu105]

Im still waiting for the others in dev team to comment

On Wed, 23 Sep 2015 7:05 am LiuXiaoJie [email protected] wrote:

Is there any update on this? Really think it is useful.

—
Reply to this email directly or view it on GitHub
https://github.com/jhipster/generator-jhipster/issues/1995#issuecomment-142445911
.

[rwinch]

Spring Security's ACL support is quite prescriptive and thus limited. However, it is very difficult to provide something generic that users want want because authorization rules vary so drastically.

If you have custom rules the easiest approach is to use standard Spring Beans and SpEL expressions. This approach is great because the authorization logic is placed in standard beans. For example, you could do something like this:

@PreAuthorize("@authz.canRead(principal, returnObject)")
Message findOne(Long id);

@PreAuthorize("@authz.canRead(principal, returnObject)")
Message findBySubject(String subject);

@Component("authz")
public class Authz {
    public boolean canRead(User user, Message message) {
        ...
    }
}

Spring Security 4.1 will make this approach easier by allowing meta-annotations. For example:

@PreAuthorize("@authz.canRead(principal, returnObject)")
@Retention(RUNTIME)
public @interface ReadableMessage {}

@ReadableMessage
Message findOne(Long id);

@ReadableMessage
Message findBySubject(String subject);

It is important to note that the authorization support at a domain level (what ACL support is aimed at) is only valuable in terms of providing an additional layer of security. This is because we cannot filter the results from an entire database in memory. For example, filtering either List<Domain> findAll() or Page<Domain> findAll(Pageable p) in a real system does not scale. Instead, we must modify the queries to ensure that only the results that we are allowed are returned.

To simplify this Spring Security allows for customizing Spring Data queries using SpEL. We also hope to provide Spring Data ACL support soon.

[deepu105]

@rwinch Thanks for the update. so if I understand your comment properly, then the solution I suggest is inline with Spring security way of doing role management?

Anyway what Im suggesting is a simple mechanism to checkif a user has appropraiet access right for a particular module/entity so that the admin can decide who can see/create what

Guys @jdubois @atomfrede @gzsombor @andidev @gmarziou @moifort if you are OK with this I can start work after next week and put up my fork with the implementation for your review

[andidev]

I leave a blank vote on since I'm a bit unfamiliar with security issues in general.

[jdubois]

I don't think that can work correctly with Hibernate, and I also think that's what @rwinch means.

-> for me this should be done in business methods, and a security framework can't do this correctly (in particular if you use Hibernate/JPA)

@deepu105 you could start be doing a POC or a "tips", so we can see how your idea works in the real world -> don't do the work of templating this right now, it's a huge work

[deepu105]

@jdubois Im doing it already for my application with a more complex use
case and its working perfectly, i dont get what hibernate issue you mean, i
haven't had any so far, anyway ill try to put up a sample soon.

This is not a tip material as would involve changing a lot manually then
On 25 Sep 2015 04:48, "Julien Dubois" [email protected] wrote:

I don't think that can work correctly with Hibernate, and I also think
that's what @rwinch https://github.com/rwinch means.

-> for me this should be done in business methods, and a security
framework can't do this correctly (in particular if you use Hibernate/JPA)

@deepu105 https://github.com/deepu105 you could start be doing a POC or
a "tips", so we can see how your idea works in the real world -> don't do
the work of templating this right now, it's a huge work

—
Reply to this email directly or view it on GitHub
https://github.com/jhipster/generator-jhipster/issues/1995#issuecomment-143046630
.

[jdubois]

For the Hibernate issue:

• Let's imagine an Author has many Books
• You have the right to edit authors, but not books
• So you put the "ACL" on the "updateAuthor" method -> you have write access an "Author", no problem
• Now imagine you get an author, do a "getBooks" and edit the title of one of the books. You're not doing any "save()" or anything. As you are in a transaction, Hibernate will automatically save the edited book at the end of the method -> here is the issue

-> I don't think you can handle this with annotations, or you would need to look at all the dirty objects in the Hibernate session and see for each of them if you have the right to modify them, and that would be a huge job.

[deepu105]

Now i understand.
Yes we wont be able to handle that and many other specific scenarios but
what we generate by default doesnt let you edit a child entity anyway so
this will work for what we genrate. Of course if the user edits it to have
a child edited within a transaction then he needs to handle to logic to
verify access as well, which again can be easily added at service layer or
at repository layer. As you said that would be a business logic.

We cant do everything rite, what i propose is just a starter and an
improvement over current hard coded logic
On 25 Sep 2015 15:51, "Julien Dubois" [email protected] wrote:

For the Hibernate issue:

• Let's imagine an Author has many Books
• You have the right to edit authors, but not books
• So you put the "ACL" on the "updateAuthor" method -> you have write
  access an "Author", no problem
• Now imagine you get an author, do a "getBooks" and edit the title of
  one of the books. You're not doing any "save()" or anything. As you are in
  a transaction, Hibernate will automatically save the edited book at the end
  of the method -> here is the issue

-> I don't think you can handle this with annotations, or you would need
to look at all the dirty objects in the Hibernate session and see for each
of them if you have the right to modify them, and that would be a huge job.

—
Reply to this email directly or view it on GitHub
https://github.com/jhipster/generator-jhipster/issues/1995#issuecomment-143151800
.

[trevershick]

I'm right in the middle of implementing this on top of the JHipster stack. If you guys decide to move forward with it, you're more than welcome to any of the source. I ended up using a custom GlobalMethodSecurityConfiguration so that i could specify a RoleVoter that uses '' as a role prefix. This way i can use ROLE_ADMIN but then use OP_PLATFORM_CR (for create platform record). I then modify the hasRole on the client side to allow wildcards (ex. has-role="OP_PLATFORM_*").

The UI below is built dynamically based on operation 'groups'. At any rate, let me know if you want any info regarding the implementation. I think this could be a great feature! Perhaps an option upon creation though like 'Use customizable security roles [Yes|No]' or something like that. It's probably a bit heavy to use by default.

None of this is ACLs by the way, just customizable roles, so it shouldn't have the issues you mentioned above.

[mmaask]

That looks sexy, I'd personally be interested to see the implementation for sure. (Y)

[phouverneyuff]

Now that you evoluted in this topic, I will do my suggestions and share my
experience.

Currently, I work in one enterprise that have one enterprise solution for
security.

We have a separately application that we can create user, permission, role,
associate role with permission, role with user, ... and have a API to
access and know if the user have the permission. We have more than 500
application with some many logic and work perfectly with this approach.

There's other features that solve other problems with the business logic,
because the role, permission and user don't resolve everything, but resolve
most the problems.

If implemented, I can propose other features for improve the logic with
security to be more generic as possible.

One tip: permission should be in facade layer. Security is more for
business logic than repository (dao). If you implement in repository,
you'll have problem with examples book and authors. But, we can use the
Resource (api endpoint) like business logic and put the @RequiredPermission
there. If you will save author with book, and you have permission for save
author in API, will save both.

[trevershick]

I'll get it pushed up somewhere @Vaelyr ... i think for now it's actually in my AWS codecommit repo.

[deepu105]

@Vaelyr @trevershick this looks nice indeed, but I dont think we want to start complicated, im working on a simpler dynamic role management, once that is done we can slowly add more fetaures

[mmaask]

Of course, I am just interested to see different security solutions on Spring Boot and Angular overall for further reference in any upcoming projects as the business needs vary very widely.

[mmaask]

@trevershick have you had a chance to share it somewhere? I'd be really interested :+1:

[trevershick]

Sorry. I've been distracted. I'll put it out in a few hours.

Sent from my iPhone

On Oct 23, 2015, at 7:09 AM, Vaelyr [email protected] wrote:

@trevershick have you had a chance to share it somewhere? I'd be really interested

―
Reply to this email directly or view it on GitHub.

[trevershick]

This is rough. I just got it working and was iterating over the features. You'll just have to accept it how it is for now. It's little more than jhipster with AdminLTE over the top of it with basic role management.
https://github.com/trevershick/shiken

[jdubois]

@deepu105 I understand you will make this as a JHipster module, so I'm closing this here.

[deepu105]

Yes I can try atleast :)

On Mon, Jan 4, 2016 at 10:31 PM, Julien Dubois [email protected]
wrote:

@deepu105 https://github.com/deepu105 I understand you will make this
as a JHipster module, so I'm closing this here.

—
Reply to this email directly or view it on GitHub
https://github.com/jhipster/generator-jhipster/issues/1995#issuecomment-168691803
.

thank you,
Deepu.k.s

[deepu105]

@jdubois I was rethinking this in the wake of our microservices offering. Do you think our current role management is sufficient? as per my original point above in the first comment its not flexible as its hard coded in the routes and resources. adding additional roles are a pain and with microservices how will we manage who has access to what.

I thought of this as a Module but that would require touching a lot of files and still think thats its high time we move from current static role management to a more dynamic one in the generator itself as it would retain current behavior with added advantage to the user to create new roles and change access control on the fly.

We could either my original solution of using spring security accessDecisionManager or we can explore some other option (definetely not Spring ACL)

yes this would still not address business rules and data layer ACL but it would be much better default than our current hard coded roles. can you reconsider here is a POC, havent added the UI to create and maintain roles but the backend is there. https://github.com/deepu105/jhipster-roles

[jdubois]

In a microservices architecture, the limitations of Spring Security are indeed more important.

In my current idea, we would have a custom Zuul filter that handles security. This filter will indeed need to dynamically check security roles, which could be done by just using the normal Spring Security API.

Then, this doesn't prevent the microservice application to do its own checks: that's already working today, in fact.

[deepu105]

So can we do it?
On 11 Feb 2016 22:07, "Julien Dubois" [email protected] wrote:

In a microservices architecture, the limitations of Spring Security are
indeed more important.

In my current idea, we would have a custom Zuul filter that handles
security. This filter will indeed need to dynamically check security roles,
which could be done by just using the normal Spring Security API.

Then, this doesn't prevent the microservice application to do its own
checks: that's already working today, in fact.

—
Reply to this email directly or view it on GitHub
https://github.com/jhipster/generator-jhipster/issues/1995#issuecomment-182878203
.

[jdubois]

I need to have a look at Zuul filters -> I will do one on rate limiting, do you want to do one on user authentication and roles management?
Besides, I'm not sure those should be generated -> we would need to have our own lib, probably

[deepu105]

Im not very familiar with zul, ill try to take a look and understand. What
about monolithic app it would need a solution as well.
On 12 Feb 2016 17:42, "Julien Dubois" [email protected] wrote:

I need to have a look at Zuul filters -> I will do one on rate limiting,
do you want to do one on user authentication and roles management?
Besides, I'm not sure those should be generated -> we would need to have
our own lib, probably

—
Reply to this email directly or view it on GitHub
https://github.com/jhipster/generator-jhipster/issues/1995#issuecomment-183253637
.

[jdubois]

Still, should this be generated or not? I'm thinking and more and more we should have our own libraries, where we store all those things instead of generating them. That should make our backend code much lighter, and also limit our maintenance work

[mraible]

I made a similar change in AppFuse a few years ago. Instead of generating all the code for users, and allowing them to own everything, I moved to a model where most dependencies were downloaded. The result was somewhat of a backlash. Users were used to having full-control over their projects and I had to add support for a "full-source" option where the dependencies could be converted to source code in the project. I did this with a Maven plugin and SVN talking to GitHub's API.

FWIW, I don't know that maintenance will be reduced. In my experience, users will want the ability to customize the libraries we provide. This results in more tickets rather than SO answers on how to customize.

[deepu105]

I also have Matt's point of view on this. I mean security and role
management atleast would be customised a lot by people and one of the
strength for Jhipster is providing full control to users.

I mean if there is something which we are very sure that will never need a
change or customisations we can make it a lib but otherwise it would be
better to generate it.

Role management should definitely be generated in my point of view as its
based on spring security and users can do a lot of tweaking as per business
needs
On 12 Feb 2016 20:52, "Matt Raible" [email protected] wrote:

I made a similar change in AppFuse a few years ago. Instead of generating
all the code for users, and allowing them to own everything, I moved to a
model where most dependencies were downloaded. The result was somewhat of a
backlash. Users were used to having full-control over their projects and I
had to add support for a "full-source" option where the dependencies could
be converted to source code in the project. I did this with a Maven plugin
and SVN talking to GitHub's API.

FWIW, I don't know that maintenance will be reduced. In my experience,
users will want the ability to customize the libraries we provide. This
results in more tickets rather than SO answers on how to customize.

—
Reply to this email directly or view it on GitHub
https://github.com/jhipster/generator-jhipster/issues/1995#issuecomment-183311870
.

[jdubois]

OK, I'm trusting your experience there guys!
Le 12 févr. 2016 4:50 PM, "Deepu K Sasidharan" [email protected] a
écrit :

I also have Matt's point of view on this. I mean security and role
management atleast would be customised a lot by people and one of the
strength for Jhipster is providing full control to users.

I mean if there is something which we are very sure that will never need a
change or customisations we can make it a lib but otherwise it would be
better to generate it.

Role management should definitely be generated in my point of view as its
based on spring security and users can do a lot of tweaking as per business
needs
On 12 Feb 2016 20:52, "Matt Raible" [email protected] wrote:

I made a similar change in AppFuse a few years ago. Instead of generating
all the code for users, and allowing them to own everything, I moved to a
model where most dependencies were downloaded. The result was somewhat
of a
backlash. Users were used to having full-control over their projects and
I
had to add support for a "full-source" option where the dependencies
could
be converted to source code in the project. I did this with a Maven
plugin
and SVN talking to GitHub's API.

FWIW, I don't know that maintenance will be reduced. In my experience,
users will want the ability to customize the libraries we provide. This
results in more tickets rather than SO answers on how to customize.

—
Reply to this email directly or view it on GitHub
<
https://github.com/jhipster/generator-jhipster/issues/1995#issuecomment-183311870

.

—
Reply to this email directly or view it on GitHub
https://github.com/jhipster/generator-jhipster/issues/1995#issuecomment-183382716
.

[deepu105]

Ok im gonna work on this soon. we can have something basic first then we can see how to improve that. this would also solve the concern raised in #3246 about having role details on the client code

[deepu105]

@trevershick with our new microservice support your way of doing the dynamic roles seems more future proof to me, could you share your current code for this so that I can try to incorporate some of it? or if you have time we can collaborate on a fork and merge it here

I would also be trying to make it configurable in a microservice architecture so that you have visibility over our microservice apps and entities and you can create flexible roles on the gateway

[trevershick]

I haven't taken it any further than what's here https://github.com/trevershick/shiken . Sorry I've been working on other goals.

[deepu105]

Ok thanks :)
On 26 Mar 2016 06:18, "Trever Shick" [email protected] wrote:

I haven't taken it any further than what's here
https://github.com/trevershick/shiken . Sorry I've been working on other
goals.

—
You are receiving this because you modified the open/close state.
Reply to this email directly or view it on GitHub
https://github.com/jhipster/generator-jhipster/issues/1995#issuecomment-201547158

[deepu105]

@ddewaele here is my sample app with dynamic role management. Your feedback is welcome. The approach is explained here

[ddewaele]

@deepu105 : Looks really nice ... I guess the fact that during user create / update the role list is still static (role_admin / role_user) is a small oversight ?

👍 for having this in the main generator. Would be a great added value.

[deepu105]

Not oversight, I havent completed the coding in the sample yet :) i wantef
feedback b4 investing more time on this
On 27 Apr 2016 05:10, "Davy De Waele" [email protected] wrote:

@deepu105 https://github.com/deepu105 : Looks really nice ... I guess
the fact that during user create / update the role list is still static
(role_admin / role_user) is a small oversight ?

👍 for having this in the main generator. Would be a great added value.

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
https://github.com/jhipster/generator-jhipster/issues/1995#issuecomment-214887080

[jdubois]

I had a quick look, indeed it's quite small and should be easy to use.
Then I already have too many people telling me we generate too much code -> could this be in a module instead? Not everybody will want it, so it should be optional

[deepu105]

Ok let me try to make it a module with some dirty hacks of course.
On 3 May 2016 00:12, "Julien Dubois" [email protected] wrote:

I had a quick look, indeed it's quite small and should be easy to use.
Then I already have too many people telling me we generate too much code
-> could this be in a module instead? Not everybody will want it, so it
should be optional

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
https://github.com/jhipster/generator-jhipster/issues/1995#issuecomment-216279797

[ddewaele]

2 remarks :

1) Is it an option to have the dynamic role part in the generator ?

• The ability to do CRUD operations on roles
• When creating a user, show a list of roles from the DB (as opposed to static hardcoded list today ?)

I think this is the more basic functionality that jHipster should offer at its core as it is already doing user mgmt. (it is limiting at the moment that the roles are hardcoded)

2) Can we make the fine-grained entity based authorization optional in the generator (by asking a question) ?

[jdubois]

There's a difference with our current code: currently we just configure standard Spring Security features, here it's extending what it does.
BTW you can bypass this solution when you use relationships, so it's handy but not perfect, and people (like me) might prefer to handle this kind of use case in their business logic.

[ddewaele]

But simply having a CRUD view on jhi_authority wouldn't extend Spring Security right ?
It would allow jHipster admins to define roles, and when creating users assign these newly created roles. That in itself would already be a nice feature.

[jdubois]

Oh yes, sorry. It's something I wanted to do but I forgot!

[deepu105]

Just crud on jhi_authority alone doesn't offer much in my opinion coz we
hardcode the ROLES at client side and server side so to have a new ROLE you
have to add it at lot of places. I agree what I proposed is not perfect but
its definitely better than the current hard coded ones. what we provide as
default might be good enough for POCs and small applications but it
will definitely not scale for larger applications.

Thanks & Regards,
Deepu

On Tue, May 3, 2016 at 3:19 PM, Julien Dubois [email protected]
wrote:

Oh yes, sorry. It's something I wanted to do but I forgot!

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
https://github.com/jhipster/generator-jhipster/issues/1995#issuecomment-216456690

[ddewaele]

My use-case is perhaps a little bit different in the sense that I use jHipster as an oauth2 authorization server and do authorization checks downstream in our underlying (micro)services.

In this case having a CRUD on jhi_authority to create new roles and assign them to users makes a lot of sense.

I also like your entity based authorization mechanism. For me this type of thing would also fit in the generator as it is pretty isolated / loosely coupled, and can be "disabled" relatively easy. (but that's something you guys need to decide).

But if you at point would consider making role management part of the generator that would be great as well.

[lordlothar99]

Hi all

just a comment about ACL security decisions : I recently put a strategy-oriented Spring Security ACL implementation : strategy-spring-security-acl

it's also based on Spring's pre/post annotations, and injects ACL restriction criterias in JPA / ElasticSearch queries so data is automatically filtered depending on user's habilitation

[jdubois]

@deepu105 have you moved forward on making this a module? Can we close this ticket?

[deepu105]

I tried to make a module but it was very hacky and I wasnt satisfied with
the results. So unless there is an interest in having this in the main
generator I dont think ill proceed this. So if we ever want this by default
Ill do it else lets close it. Anyways so far only few people asked for this
so i would assume majority of users are implementing their own solutions
for this.

But I still think there is value in generating this by default as I find
our current solution very basic and not very intuitive.
On 1 Jun 2016 00:02, "Julien Dubois" [email protected] wrote:

@deepu105 https://github.com/deepu105 have you moved forward on making
this a module? Can we close this ticket?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/jhipster/generator-jhipster/issues/1995#issuecomment-222735979,
or mute the thread
https://github.com/notifications/unsubscribe/ABDlF9dCuW1Q6sfq5f9PIZ0GEqSl3iGiks5qHFutgaJpZM4F7gLt
.

[Mabrosche]

No, no, guys, seriously :), it`s the hardest topic, really most of new comers like me, struggling with good implementation of such Features (Security(JWT,OAuth)/User Management//Social auth). You seriously have to think about adding such a module or leaving it in the main generator, I definitely believe that it will increase the attractiveness to the project.

[ricardocosta]

I've been waiting for this for quite some time. Security/Authentication/Authorization are always important aspects to get right and, having little experience, the chances of doing something wrong increase. So, either directly on the main generator or via module, I'd very much appreciate this feature.

[jdubois]

Thanks @deepu105 - I see in the comment many people who wants this after all... Guys, if everybody wants this but nobody participates, that's hard for us...
My current opinion is that we are currently just a generator, and as such we just configure Spring Security for you. And it looks like it's not enough for many people.
Maybe it's time to re-open the discussion on making a "JHipster library", that would include such additional code? I'll open a vote on the dev mailing list.

[ddewaele]

Wouldn't adding CRUD functionality on the authorities (much like we already have on the users) make sense in the jHipster main generator ? My original feature request for that was closed and got linked to this issue.

I understand that this fine grained entity based authorization might be taking it a bit too far (although for me it could be part of the generator), but having the ability to create/update/delete roles in jHipster would still make a lot of sense in the generator.

[deepu105]

I guess that shouldnt hurt. DO you want to PR that?

Thanks & Regards,
Deepu

On Mon, Jun 13, 2016 at 3:29 PM, Davy De Waele [email protected]
wrote:

Wouldn't adding CRUD functionality on the authorities (much like we
already have on the users) make sense in the jHipster main generator ? My original
feature request
https://github.com/jhipster/generator-jhipster/issues/3399 for that was
closed and got linked to this issue.

I understand that this fine grained entity based authorization might be
taking it a bit too far (although for me it could be part of the
generator), but having the ability to create/update/delete roles in
jHipster would still make a lot of sense in the generator.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/jhipster/generator-jhipster/issues/1995#issuecomment-225507321,
or mute the thread
https://github.com/notifications/unsubscribe/ABDlF6Y_UfnkRyeWpYx2OsUSUWAystEtks5qLQb0gaJpZM4F7gLt
.

[larsenje]

I'd recommend not having CRUD on authorities. Then you have to work out a strategy for migrating that data between environments since the code depends on it. A cleaner solution would be to use
loadUpdateData instead

<loadUpdateData` encoding="UTF-8"
                  file="config/liquibase/authorities.csv"
                  separator=";" 
                  primaryKey="id"
                  tableName="jhi_authority"/>

Then you can just edit the csv file, and the new authorities will be in all environments will each deployment.

This will need to be in its own changeset, so it can have runOnChange=true. Then everytime you add data to that file, it will do an upsert (it won't delete rows if you remove them from the csv).

What do you guys think? I could put together a PR for that if you'd be interested.

[deepu105]

This issue is open almost for a year now. I want to either implement this or close it. @jdubois I still feel that this would be a very valuable addition to JHipster, a lot of people have asked me for this feature. SO if you are ok with this I'll implement it else lets close this.

[sendilkumarn]

lets do it 👍

List down what are pending we will close this. Lets have a working proto and then discuss on that.

[deepu105]

There is already a working proto shared earlier in comments

Thanks & regards,
Deepu
On 24 Jul 2016 21:02, "Sendil Kumar N" [email protected] wrote:

lets do it 👍

List down what are pending we will close this. Lets have a working proto
and then discuss on that.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/jhipster/generator-jhipster/issues/1995#issuecomment-234783617,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABDlF8uvNaztKLr9Sg8_Yeo9UNh5x7Rtks5qY4WAgaJpZM4F7gLt
.

[jdubois]

Guys, you know I'm not a big fan of this, but indeed many people are interested and want to have it -> can't this be an option, or a specific sub-generator? At some point we discussed about a module, but I guess this should better be in the main generator
-> my current fear is that this will clash with the AngularJS 2 migration, as I guess you're going to have some front-end changes for this. So I would like first to have the AngularJS 2 code ready, and then this feature on top of it. Does that sound OK to you?

[deepu105]

That should be fine, lets do it after angular 2

[jdubois]

OK, @deepu105 this has been opened for so long, can we close it, and then we'll discuss this again after AngularJS 2?
Anyway I'd like us to focus on AngularJS 2, this is what everybody is waiting for, and that's a huge work.

[deepu105]

OK. But dont we want this open to track?

Thanks & regards,
Deepu
On 2 Aug 2016 19:48, "Julien Dubois" [email protected] wrote:

OK, @deepu105 https://github.com/deepu105 this has been opened for so
long, can we close it, and then we'll discuss this again after AngularJS 2?
Anyway I'd like us to focus on AngularJS 2, this is what everybody is
waiting for, and that's a huge work.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/jhipster/generator-jhipster/issues/1995#issuecomment-236918613,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABDlF8Of-3N_clakirDWvqZ04Lc3lMj6ks5qb1HEgaJpZM4F7gLt
.

[jdubois]

It's just because I don't want lots of long-running opened issues. People (including me) have a look at the opened bugs page, and it's confusing to have all those opened.
We can still track it with the "willdolater" badge. And we will either re-open it, or open a new ticket as in the future we might have new ideas, and the code will have changed anyway, so it might not be 100% valid anymore. I have no problem with opening lots of tickets, as long as they don't stay open for too long.

[deepu105]

Ok

Thanks & regards,
Deepu
On 2 Aug 2016 20:46, "Julien Dubois" [email protected] wrote:

Closed #1995 https://github.com/jhipster/generator-jhipster/issues/1995.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/jhipster/generator-jhipster/issues/1995#event-742546919,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABDlF8rMdiOi83vhofvyMzGLvd5SsnMjks5qb186gaJpZM4F7gLt
.

[fsrodrig]

Hi everybody,

Any idea of when this feature will be added or if you are still planning to add it??

[Icarus0xff]

I decide to not use jhipster because of this issue. After almost 2.5 years, is there any solution of this issue? I think jhipster is great, but this feature is so important for me to build enterprise management system with micro services architecture. @deepu105 @jdubois

[cbornet]

If it's an important feature for you, maybe you could contribute it ?

[deepu105]

Building a generic Authority management solution is extremely tricky. I
tried it once and then gave up since there wasn't much interest in the
community.
Here is the repo of what I was doing
https://github.com/deepu105/jhipster-roles
Its quite old but the approach can still work and shouldn't be hard to
implement. But it might not be what everyone wants it was ok for my use
case back then.

Thanks & Regards,
Deepu

On Mon, Jul 2, 2018 at 11:18 AM Christophe Bornet [e-mail]
wrote:

If it's an important feature for you, maybe you could contribute it ?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/jhipster/generator-jhipster/issues/1995#issuecomment-401728606,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABDlFx4JOQWjmz3s-0dsD9YH_CPj7An-ks5uCeWCgaJpZM4F7gLt
.

[PierreBesson]

@laurentsorin has developed the role management feature for his project and demonstrated it in a sample app: https://github.com/laurentsorin/jhipster-role-sample/tree/role-management
He planned to create a blueprint for it but he is lacking time and feedback.
If you would like, you could create the blueprint yourself and if it is good enough, it can be promoted to "official" status.

[PierreBesson]

@laurentsorin, you have not added a licence for your code. Maybe you could put it under Apache2.

[sebastiandg7]

Any news about this? @deepu105

The main reason, as discused above, is not having to do code changes (re deploy) in order to change the permissiveness of a user Role.

About what @jdubois says about the Hibernate issue. It is present know! For the Author and Books example, a simple use case:

• A user with ROLE_EDITORIAL authority can edit Authors.

• A user with ROLE_WRITTER authority can edit Books (but ROLE_EDITORIAL users can't, just for the use case).

If during the Author edition logic you do

author.getBooks().get(0).setName("blahblah");

then you are going to modify a resource which is not supposed to be modified (or maybe not depending on the business needs and requirements). Why would you do that? This is not an authorization bypassing due to hibernate transactions, it is due to a bad business logic implementation. Think of this: if the Author update is not supposed to update it's books, then the endpoint input should not contain any Book related data... just the Author's.

The only difference with a permission based authorization would be that the user is not going to gain access to the REST endpoint because of the roles it owns but because of the permission owned by the user roles. Same happens for the frontend, the presentation of an UI component for an Author Edition will be based on if the user has a role with the permission to do it.

So, the whole permission based authorization can be achieved in two scopes:

Spring Security Authorization

In wich the main work from the jhipster side must be done. Each endpoint must be secured with at least one permission, but preferably a set of permission structures. Example approach:

@RestController  
@RequestMapping("/api/author/v1")
public class AuthorResource {

    @PostMapping("/authors")
    @PreAuthorize("hasAnyAuthority(\"" + AuthoritiesConstants.AUTHOR_CREATE + ","
        + AuthoritiesConstants.AUTHOR_ALL + "\")")
    public ResponseEntity<?> createAuthor( @RequestBody AuthorDTO authorDTO )  {
            // Create the author
            return ResponseEntity.ok();
    }

    @PutMapping("/authors")
    @PreAuthorize("hasAnyAuthority(\"" + AuthoritiesConstants.AUTHOR_UPDATE + ","
        + AuthoritiesConstants.AUTHOR_ALL + "\")")
    public ResponseEntity<?> updateExample( @RequestBody AuthorDTO authorDTO )  {
            // Update the author
            return ResponseEntity.ok();
    }

}

Business Logic Authorization (which must be done independently if a role or permission authorization is used)

Apart of the Spring Security level permission restriction, the business logic must restrict the resources operations according to each use case needs.

In adition to the previous use case.

• A user with ROLE_WRITTER authority can edit a Book only if it belongs to him.

Then...

@RestController  
@RequestMapping("/api/book/v1")
public class BookResource {

    @PutMapping("/book")
    @PreAuthorize("hasAnyAuthority(\"" + AuthoritiesConstants.BOOK_UPDATE + ","
        + AuthoritiesConstants.BOOK_ALL + "\")")
    public ResponseEntity<?> updateExample( @RequestBody BookDTO bookDTO )  {
            // Update the book only if the book belongs
            // to the user requesting the book update
            return ResponseEntity.ok();
    }

}

This gives a better access control management for the whole application.

[deepu105]

No body worked on this and I gave up due to lack of interest from
community. If you have nice Ideas I suggest you do a PR and I'll do my best
to take it forward

On Fri, 5 Oct 2018, 7:53 am Sebastian Duque Gutierrez, <
[email protected]> wrote:

Any news about this? @deepu105 https://github.com/deepu105

The main reason, as discused above, is not having to do code changes (re
deploy) in order to change the permissiveness of a user Role.

About what @jdubois https://github.com/jdubois says about the Hibernate
issue. It is present know! For the Author and Books example, a simple use
case:

-

A user with ROLE_EDITORIAL authority can edit Authors.
-

A user with ROLE_WRITTER authority can edit Books (but ROLE_EDITORIAL
users can't, just for the use case).

If during the Author edition logic you do

author.getBooks().get(0).setName("blahblah");

then you are going to modify a resource which is not supposed to be
modified (or maybe not depending on the business needs and requirements).
Why would you do that? This is not an authorization bypassing due to
hibernate transactions, it is due to a bad business logic implementation.
Think of this: if the Author update is not supposed to update it's books,
then the endpoint input should not contain any Book related data... just
the Author's.

The only difference with a permission based authorization would be that
the user is not going to gain access to the REST endpoint because of the
roles it owns but because of the permission owned by the user roles. Same
happens for the frontend, the presentation of an UI component for an Author
Edition will be based on if the user has a role with the permission to do
it.

So, the whole permission based authorization can be achieved in two scopes:
Spring Security Authorization

In wich the main work from the jhipster side must be done. Each endpoint
must be secured with at least one permission, but preferably a set of
permission structures. Example approach:

@RestController @RequestMapping("/api/author/v1")public class AuthorResource {

@PostMapping("/authors")
@PreAuthorize("hasAnyAuthority(\"" + AuthoritiesConstants.AUTHOR_CREATE + ","
    + AuthoritiesConstants.AUTHOR_ALL + "\")")
public ResponseEntity<?> createAuthor( @RequestBody AuthorDTO authorDTO )  {
        // Create the author
        return ResponseEntity.ok();
}

@PutMapping("/authors")
@PreAuthorize("hasAnyAuthority(\"" + AuthoritiesConstants.AUTHOR_UPDATE + ","
    + AuthoritiesConstants.AUTHOR_ALL + "\")")
public ResponseEntity<?> updateExample( @RequestBody AuthorDTO authorDTO )  {
        // Update the author
        return ResponseEntity.ok();
}

}

Business Logic Authorization (which must be done independently if a role
or permission authorization is used)

Apart of the Spring Security level permission restriction, the business
logic must restrict the resources operations according to each use case
needs.

In adition to the previous use case.

• A user with ROLE_WRITTER authority can edit a Book only if it
  belongs to him.

Then...

@RestController @RequestMapping("/api/book/v1")public class BookResource {

@PutMapping("/book")
@PreAuthorize("hasAnyAuthority(\"" + AuthoritiesConstants.BOOK_UPDATE + ","
    + AuthoritiesConstants.BOOK_ALL + "\")")
public ResponseEntity<?> updateExample( @RequestBody BookDTO bookDTO )  {
        // Update the book only if the book belongs
        // to the user requesting the book update
        return ResponseEntity.ok();
}

}

This gives a better access control management for the whole application.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/jhipster/generator-jhipster/issues/1995#issuecomment-427254115,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABDlF9Pjzh1XoG2g1LNRoyVJTWyQutwdks5uhvPQgaJpZM4F7gLt
.