Am 11.02.2014 um 14:09 schrieb Claudio Miranda <claudio@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@claudius.com.br
http://www.claudius.com.br
_______________________________________________
wildfly-dev mailing list
wildfly-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev

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