[wildfly-dev] add rbac support to picketlink

[Harald Pehl]

Am 11.02.2014 um 14:09 schrieb Claudio Miranda <claudio at claudius.com.br>:

> Hi, I plan to add rabc support to picketlink console + extension
> (https://github.com/picketlink2/picketlink-console)
> 
> I read the https://community.jboss.org/wiki/AccessControlNotes pages
> and docs, I understood they explain about the design of the rbac
> solution and not how to use it.
> 
> But I would like more guidance related to the code samples and how to
> protect resources accordingly to the role the user is associated.
> 
> I understand there are two places to protect resources,
> - management level, protect CLI and GUI operations
> - GUI protect and hide features from unauthorized users.

For the GUI it's mainly about hiding / disabling UI elements when the user has no sufficient rights. The meta data to decide which UI elements to show / hide are retrieved from related read-resource-description operations. So it's crucial for the console that the RBAC relevant informations are present in the r-r-d operations. 

> Should I first protect the management operations, used in management
> operations, at the extension level ?
> then proceed to protect the HAL extension ?

Yes, first step is to enrich the management operations to support RBAC. The console will leverage this information (see below)

> I looked into org.jboss.as.console.client.shared.subsys.mail.MailPresenter,
> how it is used to protect resources, but could not find how the "add",
> "remove" "enable"  buttons are hidden.
> 
> What means the annotation in the code.
> 
>    @ProxyCodeSplit
>    @NameToken(NameTokens.MailPresenter)
>    @AccessControl(resources =
> {"{selected.profile}/subsystem=mail/mail-session=*"})
>    public interface MyProxy extends Proxy<MailPresenter>, Place {}
> 
> Does @AccessControl reads the resource permission and injects some
> code to HAL understood it needs to protect it ?

The @AccessControl annotation defines the set of resources a presenter operates on. In the example it's just a single resource, but you can declare multiple ones. Based on that information, the security framework creates a security context that will be queried when authorization decisions need to be taken on the client side (like showing / hiding buttons). The @AccessControl annotation is processed once when the view is rendered for the first time. At that time read-resource-description operations are executed for the annotated resources. 

There's some more documentation about the security framework at [1]. 

[1] http://hal.github.io/developer/6_security.html

> If you can provide some guidance, would be very appreciated.

Once the server side setup is complete, you should place the @AccessControl annotations on the Proxy classes in PicketLinks HAL extension. This should give you 80% to 90% completeness. For the fine tuning I would recommend that we have some kind of coding session (irc / hangout). In any case if you have further questions, just ping me!

> 
> Thanks
> -- 
>  Claudio Miranda
> 
> claudio at claudius.com.br
> http://www.claudius.com.br
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev

---
Harald Pehl
JBoss by Red Hat
http://hpehl.info

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20140212/5206dbe1/attachment.html