[keycloak-user] Securing subpaths with specific roles

Stian Thorgersen stian at redhat.com
Thu Jul 17 08:37:52 EDT 2014


You can also use HttpServletRequest.isUserInRole. We haven't tested it with DeltaSpike, but in theory it should just work.

----- Original Message -----
> From: "Stian Thorgersen" <stian at redhat.com>
> To: "Edem Morny" <emorny at gmail.com>
> Cc: keycloak-user at lists.jboss.org
> Sent: Thursday, 17 July, 2014 1:33:39 PM
> Subject: Re: [keycloak-user] Securing subpaths with specific roles
> 
> 
> 
> ----- Original Message -----
> > From: "Edem Morny" <emorny at gmail.com>
> > To: keycloak-user at lists.jboss.org
> > Sent: Thursday, 17 July, 2014 1:20:31 PM
> > Subject: [keycloak-user] Securing subpaths with specific roles
> > 
> > Hi,
> > 
> > I'm currently using beta2 of keycloak, and we are building a new
> > application
> > with keycloak as our security platform.
> > 
> > In our web module, all pages are located under the path
> > src/main/webapps/views. Navigation to the index.xhtml file under this path
> > triggers keycloack login, as expected. We've enabled self-registration and
> > assigned the default realm role to be "user", so a new user automatically
> > obtains the "user" role. Here is a snippet of our web.xml file.
> > 
> > 
> > <security-constraint>
> > <web-resource-collection>
> > <web-resource-name>Users</web-resource-name>
> > <url-pattern>/views/*</url-pattern>
> > </web-resource-collection>
> > <auth-constraint>
> > <role-name>user</role-name>
> > </auth-constraint>
> > </security-constraint>
> > <security-constraint>
> > <web-resource-collection>
> > <web-resource-name>Supervisor</web-resource-name>
> > <url-pattern>/views/supervisor/*</url-pattern>
> > </web-resource-collection>
> > <auth-constraint>
> > <role-name>supervisor</role-name>
> > </auth-constraint>
> > </security-constraint>
> > ...
> > 
> > In effect any person with "user" role can view any content directly under
> > /views/*. However, the newly enrolled user is able to navigate to other
> > subpaths under the /views like the /views/supervisor/* which should
> > normally
> > require the user to have the additional "supervisor" role in addition to
> > being "user".
> > 
> > So I have 2 questions.
> > 1. Am I doing something wrong with regards to this setup? Does each
> > registered application also need to have roles specified, or should the
> > realm roles be enough. Or is my understanding wrong?
> 
> You'll need to more explicitly specify what patterns a user can access, as
> with that constraint you're giving permission to everything under view to
> users with the role 'user'. For example:
> 
> <web-resource-collection>
>   <web-resource-name>Users</web-resource-name>
>     <url-pattern>/views/*.jsp</url-pattern>
>     <url-pattern>/views/user/*</url-pattern>
>   </web-resource-collection>
>   <auth-constraint>
>     <role-name>user</role-name>
>   </auth-constraint>
> </security-constraint>
> 
> 
> > 2. Is there an a means to obtain the roles that a user has after logging
> > in?
> > The IDToken doesn't seem to contain any such information so I can use that
> > with some other security implementation like DeltaSpike's security support
> > in case the above is not supported.
> 
> The roles are available from the AccessToken with getRealmAccess and
> getResourceAccess methods. The AccessToken can be retrieved using getToken
> method on KeycloakSecurityContext
> 
> > 
> > Looking forward to your response. Cheers.
> > 
> > 
> > 
> > _______________________________________________
> > keycloak-user mailing list
> > keycloak-user at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-user
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user
> 


More information about the keycloak-user mailing list