8:47 a.m.
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/o...
[3]
https://github.com/wildfly/wildfly/blob/master/controller/src/main/java/o...
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