Authz #1
Comments
|
I agree. Thanks for the feedback. It's easy enough to just add the javascript for that, but I'm wondering if we need some wrapper code to make it easier to consume in Angular. I haven't used the authz stuff myself so I'd really love to hear your opinion on what authz support would look like. |
|
As you said, is just add the javascript. However, it should support rpt interchange (reading WWW-Authenticate header) like the keycloak example in angular 1 |
|
For authorization, some Http Interceptor is necessary. The interceptor should add authorization header to each request which goes to REST API. When Keycloak Policy enforcer returns unauthorized, it also returns URL on which the client can get the requesting party token containing necessary permissions. The example is in the link which carlosthe19916 posted (the photoz app). The photoz app contains angular.js (not Angular 2+) client and Rest API protected by the policy enforcer. I have seen a Keycloak HTTP interceptor for Angular 4 implemented here: Later, I also found this library, which seems to have a rich API (I am going to test it next week): |
|
One more comment: Angular as a public client should not use standard authentication flow. Instead, it should use implicit flow. In implicit flow, the client receives an access code in the hash (#) segment in the redirect URL from the server. The hash segment is then only read by the keycloak.js. https://auth0.com/docs/api-auth/which-oauth-flow-to-use#is-the-client-a-native-app-or-a-spa- The disadvantage of the implicit flow is that the client does not receive authorization token and thus cannot refresh access token, instead, it should log in again with keycloak. Logging in with keycloak should be done again in a hidden iframe to prevent disrupting the user. https://manfredsteyer.github.io/angular-oauth2-oidc/angular-oauth2-oidc/docs/additional-documentation/refreshing-a-token-(silent-refresh).html |
|
I have taken a look at the KeycloakHttp class. Currently, the KeycloakHttp adds an Access Token to every HTTP request. So instead of sending the Access Token with HTTP requests, we should be sending RPT (or send nothing if we do not have an RPT yet). Based on RPT, the Keycloak policy enforcer either permits the access or it sends Unauthorized 401. If the Resource server sends 401 Unauthorized then in the response it also sends header "www-authenticate". The www-authenthicate header either contains a permission ticket or URL to entitlement API. This is based on the configuration of the policy enforcer. Nevertheless: Keycloak Authorisation JavaScript keycloak-authz.js (https://github.com/keycloak/keycloak-js-bower/blob/master/dist/keycloak-authz.js) can consume the contents of www-authenthicate header (regardless of whether it is a permission ticket or entitlement URL). It encapsulates a call to Keycloak server and returns an RPT. With the new RPT we can try to obtain the resource from Resource server again. In this flow: |
|
Keycloak 4 removes UMA and uses UMA2 protocol. I suggest we use the uma2 already. I just looked at the keycloak-authz.js shipped with 4.Beta1 and it already calls uma2 api endpoint. |
It would be great to add authz
The text was updated successfully, but these errors were encountered: