merge blog "Protect your applications with Jakarta Security, MicroProfile JWT, and Keycloak" into staging #3442
Conversation
Co-authored-by: Adam Yoho <ayoho@us.ibm.com>
There was a problem hiding this comment.
Overall, a great topic and nice to see how developers could do this in their own applications. However, at the moment it feels too much like technical documentation and less like a blog. It would be really nice to have some more context as to why developers should consider using it, benefits, etc. Please see individual comments throughout blog for more details.
|
|
||
|
|
||
| Open Liberty can easily integrate with Keycloak, which can be used as an OpenID Connect Provider, using Jakarta Security and MicroProfile JWT. | ||
| In this blog post, a Keycloak server has been setup with a realm called `openliberty` which contains a client called `sample-openliberty-keycloak` and the realm roles of `admin` and `user`. Additionally in the `sample-openliberty-keycloak` client, client authentication has been enabled, `http://localhost:9090/Callback` has been added as a valid redirect URI, and the `microprofile-jwt` client scope has been set to `Default`. |
There was a problem hiding this comment.
I think we're missing a bit of context here on why someone may want to use Keycloak and it's advantages. Could possibly also cover more on why integration with Jakarta EE and MP or even alternatives and why this is a good choice?
At the moment, it feels like we jump straight into a technical tutorial/documentation without context of why I'd want to read this or use it.
There was a problem hiding this comment.
Also feel like it jumps into a lot of specific technical jargon which should be explained (e.g. what is a realm?).
There was a problem hiding this comment.
Might also be nice to give a short sentence on what Jakarta security and what MicroProfile JWT are (maybe with links to our guides on these in case readers have not used them before).
|
|
||
| == Obtaining an access token from Keycloak using Jakarta Security | ||
|
|
||
| With the new `@OpenIdAuthenticationMechanismDefinition` annotation introduced in link:https://openliberty.io/docs/latest/reference/feature/appSecurity-5.0.html[Jakarta Security 3.0], you can easily authenticate users of your application with Keycloak and obtain an access token. |
There was a problem hiding this comment.
Similarly here, may be nice to say what users would have had to have done before this new annotation (i.e. I assume a longer or harder process) and then say why this new annotation and keycloak make dev lives easier. Want more why here as well as technical how.
|
|
||
| In this example, the `providerURI` is the discovery endpoint for the `openliberty` realm, the `clientId` is the client ID of the `sample-openliberty-keycloak` client, and the `clientSecret` is the secret belonging to the `sample-openliberty-keycloak` client. By default, the redirect URI is set to `http://localhost:9090/Callback` and `redirectToOriginalResource` is set to `true` to redirect users from the redirect URI back to the originally requested resource. Lastly, `notifyProvider` in the `@LogoutDefinition` is set to `true` to also log the user out of Keycloak when a logout occurs in your Open Liberty application. | ||
|
|
||
| Now, with this annotation set up, your REST endpoints can be protected using the `@RolesAllowed` annotation which will trigger the authentication flow when a user tries to access the endpoint. |
There was a problem hiding this comment.
More why here would be nice - why is protection needed? what do roles help us with and how?
|
|
||
| link:https://openliberty.io/docs/latest/reference/feature/mpJwt-2.1.html[MicroProfile JWT] can easily be used to consume access tokens sent as bearer tokens. | ||
|
|
||
| This example shows the link:https://openliberty.io/docs/latest/microprofile-config-properties.html#jwt[MicroProfile Config properties] required to validate an access token issued by the `openliberty` realm in Keycloak. |
There was a problem hiding this comment.
Feels like MP config came out of the blue in this part. Maybe add in why it's being used? Or into it more.
|
|
||
| Now, MicroProfile JWT is setup to validate access tokens issued by the `openliberty` realm sent as bearer tokens to resources protected using the `@RolesAllowed` annotation. | ||
|
|
||
| Similarly to the previous section, this example shows a JAX-RS resource which contains a `/username` endpoint only accessible by users with the `admin` role and a `/os` endpoint accessible by both users with the `admin` role and users with the `user` role. |
There was a problem hiding this comment.
This paragraph is a little confusing in that we're referring to both the section before and the section after, which makes it hard to read/follow. Is there a way that we could maybe better set up this whole section to make this transition easier/make more sense. So maybe introduce both options up front, then go through each one?
|
Targeting February 2024 for this blog |
for #3003
post on blogs-draft site:
https://blogs-draft-openlibertyio.mqj6zf7jocq.us-south.codeengine.appdomain.cloud/blog/2023/09/30/keycloak-with-openliberty.html
screenshot from blogs-draft site:
