[wildfly-dev] add rbac support to picketlink

Brian Stansberry brian.stansberry at redhat.com
Tue Feb 11 09:47:39 EST 2014


Be sure to coordinate with Pedro Igor Silva (in cc), who is very 
actively working on these subsystems.

Start with the extension. The console is primarily driven by security 
information returned by the server side.[1] Harald Pehl can comment on 
any console work required beyond getting the correct data returned from 
the server.

If there's anything in your subsystems that might be configurable from 
the Deployer role, let me know.

Otherwise, the primary task is to identify sensitivity classifications 
associated with your subsystems. There are two basic aspects:

1) Which of the core sensitivity classifications[2] apply to 
resources/attributes/operations in your subsystem. The ones likely to be 
relevant are

a) CREDENTIAL, which would be applied to any attributes that represent 
usernames or passwords.

b) SECURITY_REALM_REF, which would be applied to any attribute that 
contains the name of a security-realm resource.

b) SECURITY_DOMAIN_REF, which would be applied to any attribute that 
contains the name of a security-domain resource.

2) Any subsystem-specific sensitivity classifications you wish to 
introduce. I expect there will be some for these subsystems! If you look 
in your IDE in the usages of the constructor at [3] in other subsystems 
you can get a sense of how that's used.

The idea here is to find a sweet spot in terms of granularity of 
classifications. When you create these you set up defaults (is 
addressing a resource sensitive, are reads sensitive, are writes 
sensitive). You want as few of these as possible while letting users who 
might disagree with some default to change it without affecting stuff 
they don't want to change. This may be very simple though; just one 
classification for an entire subsystem.

That's enough for one email; we can chat later about further details.

[1] Primarily by calling the equivalent to the 
:read-resource-description(access-control=trim-descriptions) CLI op. You 
can try that yourself in the CLI to see the output.

[2] 
https://github.com/wildfly/wildfly/blob/master/controller/src/main/java/org/jboss/as/controller/access/management/SensitiveTargetAccessConstraintDefinition.java

[3] 
https://github.com/wildfly/wildfly/blob/master/controller/src/main/java/org/jboss/as/controller/access/management/SensitiveTargetAccessConstraintDefinition.java#L66

On 2/11/14, 7:09 AM, Claudio Miranda wrote:
> 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.
>
> Should I first protect the management operations, used in management
> operations, at the extension level ?
> then proceed to protect the HAL extension ?
>
>
> 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 ?
>
> If you can provide some guidance, would be very appreciated.
>
> Thanks
>


-- 
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat


More information about the wildfly-dev mailing list