forked from apache/incubator-kie-kogito-examples
-
Notifications
You must be signed in to change notification settings - Fork 0
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
usertasks with security oidc - keycloak (apache#1)
- Loading branch information
1 parent
f3afb63
commit 4d939b2
Showing
15 changed files
with
3,026 additions
and
2 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,20 @@ | ||
bin/ | ||
/target | ||
/local | ||
|
||
# Eclipse, Netbeans and IntelliJ files | ||
/.* | ||
!.gitignore | ||
/nbproject | ||
/*.ipr | ||
/*.iws | ||
/*.iml | ||
|
||
# Repository wide ignore mac DS_Store files | ||
.DS_Store | ||
*~ | ||
/settings*.xml | ||
*.db | ||
*.tlog | ||
|
||
workspace |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,214 @@ | ||
# Kogito user task orchestration | ||
|
||
## Description | ||
|
||
A quickstart project shows very typical user task orchestration. It comes with two tasks assigned | ||
to human actors via groups assignments - `managers`. So essentially anyone who is a member of that | ||
group can act on the tasks. Though this example applies four eye principle which essentially means | ||
that user who approved first task cannot approve second one. So there must be always at least two | ||
distinct manager involved. | ||
|
||
This example shows | ||
|
||
* working with user tasks | ||
* four eye principle with user tasks | ||
|
||
|
||
<p align="center"><img width=75% height=50% src="docs/images/process.png"></p> | ||
|
||
|
||
## Build and run | ||
|
||
### Prerequisites | ||
|
||
You will need: | ||
- Java 1.8.0+ installed | ||
- Environment variable JAVA_HOME set accordingly | ||
- Maven 3.5.4+ installed | ||
- [jq](https://stedolan.github.io/jq) tool installed. You can download it from [here](https://stedolan.github.io/jq/download) | ||
- Docker | ||
|
||
|
||
When using native image compilation, you will also need: | ||
- GraalVM 19.1+ installed | ||
- Environment variable GRAALVM_HOME set accordingly | ||
- Note that GraalVM native image compilation typically requires other packages (glibc-devel, zlib-devel and gcc) to be installed too, please refer to GraalVM installation documentation for more details. | ||
|
||
### Starting and Configuring the Keycloak Server | ||
|
||
To start a Keycloak Server you can use Docker and just run the following command: | ||
|
||
``` | ||
docker run --name keycloak -e KEYCLOAK_USER=admin -e KEYCLOAK_PASSWORD=admin -p 8280:8080 quay.io/keycloak/keycloak | ||
``` | ||
|
||
You should be able to access your Keycloak Server at [localhost:8280/auth](http://localhost:8280). | ||
|
||
Log in as the admin user to access the Keycloak Administration Console. Username should be admin and password admin. | ||
|
||
Add the quarkus realm in two steps: | ||
1. Create new realm named 'quarkus' | ||
2. Import config [file](config/quarkus-realm.json) overwriting the existing items | ||
|
||
For more details, see the Keycloak documentation about how to create a new realm. | ||
|
||
### Compile and Run in Local Dev Mode | ||
|
||
``` | ||
mvn clean package quarkus:dev | ||
``` | ||
|
||
NOTE: With dev mode of Quarkus you can take advantage of hot reload for business assets like processes, rules, decision tables and java code. No need to redeploy or restart your running application. | ||
|
||
|
||
### Compile and Run using Local Native Image | ||
Note that this requires GRAALVM_HOME to point to a valid GraalVM installation | ||
|
||
``` | ||
mvn clean package -Pnative | ||
``` | ||
|
||
To run the generated native executable, generated in `target/`, execute | ||
|
||
``` | ||
./target/kogito-usertasks-with-security-oidc-keycloak-{version}-runner | ||
``` | ||
|
||
### Use the application | ||
|
||
Examine OpenAPI via swagger UI at [http://localhost:8080/swagger-ui](http://localhost:8080/swagger-ui) | ||
|
||
|
||
### Submit a request to start new approval | ||
|
||
To make use of this application it is as simple as putting a sending request to `http://localhost:8080/approvals` with following content | ||
|
||
``` | ||
{ | ||
"traveller" : { | ||
"firstName" : "John", | ||
"lastName" : "Doe", | ||
"email" : "jon.doe@example.com", | ||
"nationality" : "American", | ||
"address" : { | ||
"street" : "main street", | ||
"city" : "Boston", | ||
"zipCode" : "10005", | ||
"country" : "US" } | ||
} | ||
} | ||
``` | ||
|
||
Complete curl command can be found below: | ||
|
||
The application is using bearer token authorization and the first thing to do is obtain an access token from the Keycloak | ||
Server in order to access the application resources. Obtain an access token for user john. | ||
|
||
``` | ||
export access_token=$(\ | ||
curl -X POST http://localhost:8280/auth/realms/quarkus/protocol/openid-connect/token \ | ||
--user backend-service:secret \ | ||
-H 'content-type: application/x-www-form-urlencoded' \ | ||
-d 'username=john&password=john&grant_type=password' | jq --raw-output '.access_token' \ | ||
) | ||
``` | ||
|
||
``` | ||
curl -X POST -H 'Content-Type:application/json' -H 'Accept:application/json' -H "Authorization: Bearer "$access_token -d '{"traveller" : { "firstName" : "John", "lastName" : "Doe", "email" : "jon.doe@example.com", "nationality" : "American","address" : { "street" : "main street", "city" : "Boston", "zipCode" : "10005", "country" : "US" }}}' http://localhost:8080/approvals | ||
``` | ||
|
||
### Show active approvals | ||
|
||
``` | ||
curl -H 'Content-Type:application/json' -H 'Accept:application/json' -H "Authorization: Bearer "$access_token http://localhost:8080/approvals | ||
``` | ||
|
||
### Show tasks | ||
|
||
``` | ||
curl -H 'Content-Type:application/json' -H 'Accept:application/json' -H "Authorization: Bearer "$access_token 'http://localhost:8080/approvals/{uuid}/tasks?user=john&group=employees' | ||
``` | ||
|
||
Try with the manager Mary | ||
|
||
``` | ||
export access_token=$(\ | ||
curl -X POST http://localhost:8280/auth/realms/quarkus/protocol/openid-connect/token \ | ||
--user backend-service:secret \ | ||
-H 'content-type: application/x-www-form-urlencoded' \ | ||
-d 'username=mary&password=mary&grant_type=password' | jq --raw-output '.access_token' \ | ||
) | ||
``` | ||
``` | ||
curl -H 'Content-Type:application/json' -H 'Accept:application/json' -H "Authorization: Bearer "$access_token 'http://localhost:8080/approvals/{uuid}/tasks?user=mary&group=managers' | ||
``` | ||
|
||
where `{uuid}` is the id of the given approval instance | ||
|
||
|
||
### Complete first line approval task | ||
|
||
``` | ||
curl -H "Authorization: Bearer "$access_token -X POST -d '{"approved" : true}' -H 'Content-Type:application/json' -H 'Accept:application/json' 'http://localhost:8080/approvals/{uuid}/firstLineApproval/{tuuid}?user=mary&group=managers' | ||
``` | ||
|
||
where `{uuid}` is the id of the given approval instance and `{tuuid}` is the id of the task | ||
|
||
### Show tasks | ||
|
||
``` | ||
curl -H 'Content-Type:application/json' -H 'Accept:application/json' -H "Authorization: Bearer "$access_token 'http://localhost:8080/approvals/{uuid}/tasks?user=mary&group=managers' | ||
``` | ||
|
||
where `{uuid}` is the id of the given approval instance. This should return empty response as Mary was the first approver and by that can't be assigned to another one. | ||
|
||
Repeating the request with another user | ||
|
||
``` | ||
export access_token=$(\ | ||
curl -X POST http://localhost:8280/auth/realms/quarkus/protocol/openid-connect/token \ | ||
--user backend-service:secret \ | ||
-H 'content-type: application/x-www-form-urlencoded' \ | ||
-d 'username=poul&password=poul&grant_type=password' | jq --raw-output '.access_token' \ | ||
) | ||
``` | ||
|
||
``` | ||
curl -H 'Content-Type:application/json' -H 'Accept:application/json' -H "Authorization: Bearer "$access_token 'http://localhost:8080/approvals/{uuid}/tasks?user=poul&group=managers' | ||
``` | ||
|
||
Now we have the id for the second approval task | ||
|
||
### Complete second line approval task | ||
|
||
``` | ||
curl -H "Authorization: Bearer "$access_token -X POST -d '{"approved" : true}' -H 'Content-Type:application/json' -H 'Accept:application/json' 'http://localhost:8080/approvals/{uuid}/secondLineApproval/{tuuid}?user=poul&group=managers' | ||
``` | ||
|
||
where `{uuid}` is the id of the given approval instance and `{tuuid}` is the id of the task instance | ||
|
||
This completes the approval and returns approvals model where both approvals of first and second line can be found, | ||
plus the approver who made the first one. | ||
|
||
``` | ||
{ | ||
"approver": "mary", | ||
"firstLineApproval": true, | ||
"id": "20fcafed-255e-4e1b-b00f-9943aabb47fd", | ||
"secondLineApproval": true, | ||
"traveller": { | ||
"address": { | ||
"city": "Boston", | ||
"country": "US", | ||
"street": "main street", | ||
"zipCode": "10005" | ||
}, | ||
"email": "jon.doe@example.com", | ||
"firstName": "John", | ||
"lastName": "Doe", | ||
"nationality": "American" | ||
} | ||
} | ||
``` |
Oops, something went wrong.