Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Defining endpoint security through JDL #19201

Open
1 task done
SpiralUp opened this issue Jul 20, 2022 · 5 comments · May be fixed by #23740
Open
1 task done

Defining endpoint security through JDL #19201

SpiralUp opened this issue Jul 20, 2022 · 5 comments · May be fixed by #23740
Labels
area: feature request 💡 theme: security

Comments

@SpiralUp
Copy link
Contributor

Overview of the feature request

When creating an application through JHipster, it is necessary to manually adjust the security on the generated endpoints. This could be avoided if security was defined through JDL and then generated.
An example of a possible definition in JDL:

  secure _Entity_ with roles {
       ROLE_ADMIN allows (GET, PUT, POST, DELETE)
       ROLE_USER allows (GET)
  }

This should be reflected in the generation of EntityResource and EntityResourceIT.

I already have an implementation for this, so I can share it ...

Motivation for or Use Case

Now, security has to be added manually on endpoints that are generated and unit tests have to be refined manually. It seems to me that this is the most common refinement over the generated code.

Related issues or PR
  • Checking this box is mandatory (this is just to show you read everything)
@gmarziou
Copy link
Contributor

Interesting, were you able to reflect this into the API documentation?

@SpiralUp
Copy link
Contributor Author

SpiralUp commented Jul 20, 2022 •
edited

I just added a comment to the source code:


  // Security is enabled on this entity

  // Security type = roles

  // GET:    "ROLE_ADMIN", "ROLE_USER"

  // PUT:    "ROLE_ADMIN"

  // POST:   "ROLE_ADMIN"

  // DELETE: "ROLE_ADMIN"

but it's a good suggestion to make it visible in the API documentation as well - it shouldn't be hard ...

@DanielFran
Copy link
Member

@SpiralUp Are you available to contribute with a PR?

@SpiralUp
Copy link
Contributor Author

I'm available to contribute with a PR...

SpiralUp added a commit to SpiralUp/generator-jhipster-8 that referenced this issue Oct 4, 2023
@SpiralUp
Defining endpoint security through JDL
97f3f90 
This commit introduces a role-based security feature for the backend, allowing users to define security configurations using JDL clauses. Security can now be specified directly within JDL for various entities, where different roles with specified permissions are mapped to the corresponding Java entity resource files. This mapping auto-generates the requisite `@Secured({})` annotations on the endpoints, ensuring the right level of access control based on roles. Examples of the JDL security clauses include:
```
  secure entity1, entity2, entity3 with roles {
    ROLE_ADMIN allows (get, post, put, delete)
    ROLE_USER allows (get)
  }
```
and
```
  secure all except entity3 with roles {
    ROLE_ADMIN allows (get, post, put, delete)
    ROLE_USER allows (get)
  }
```
which would translate to `@Secured({ "ROLE_ADMIN" })` annotations in the generated Java code for specified endpoints. Additionally, the integration tests have been updated to consider these role-based security configurations.

Moreover, the groundwork for supporting other security types has been laid down through the inclusion of grammar and parser definitions. These additional security types encompass privilege security, organizational security, parent based security, and relation based security, although the code generators for these types are not included in this commit.

Resolves jhipster#19201
@SpiralUp SpiralUp linked a pull request Oct 4, 2023 that will close this issue
Open
SpiralUp added a commit to SpiralUp/generator-jhipster-8 that referenced this issue Oct 4, 2023
@SpiralUp
Defining endpoint security through JDL
927949c 
This commit introduces a role-based security feature for the backend, allowing users to define security configurations using JDL clauses. Security can now be specified directly within JDL for various entities, where different roles with specified permissions are mapped to the corresponding Java entity resource files. This mapping auto-generates the requisite `@Secured({})` annotations on the endpoints, ensuring the right level of access control based on roles. Examples of the JDL security clauses include:
```
  secure entity1, entity2, entity3 with roles {
    ROLE_ADMIN allows (get, post, put, delete)
    ROLE_USER allows (get)
  }
```
and
```
  secure all except entity3 with roles {
    ROLE_ADMIN allows (get, post, put, delete)
    ROLE_USER allows (get)
  }
```
which would translate to `@Secured({ "ROLE_ADMIN" })` annotations in the generated Java code for specified endpoints. Additionally, the integration tests have been updated to consider these role-based security configurations.

Moreover, the groundwork for supporting other security types has been laid down through the inclusion of grammar and parser definitions. These additional security types encompass privilege security, organizational security, parent based security, and relation based security, although the code generators for these types are not included in this commit.

Resolves jhipster#19201
@github-actions GitHub Actions
Copy link
Contributor

This issue is stale because it has been open for too long without any activity.
Due to the moving nature of jhipster generated application, bugs can become invalid.
If this issue still applies please comment otherwise it will be closed in 7 days

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
area: feature request 💡 theme: security
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Defining endpoint security through JDL SpiralUp/generator-jhipster-8
3 participants
@gmarziou @SpiralUp @DanielFran