7:09 a.m.
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
--
Claudio Miranda
claudio(a)claudius.com.br
http://www.claudius.com.br
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
4:19 a.m.
Am 11.02.2014 um 14:09 schrieb Claudio Miranda <claudio(a)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(a)claudius.com.br
http://www.claudius.com.br
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
---
Harald Pehl
JBoss by Red Hat
http://hpehl.info
3955
days inactive
3956
days old
2 comments
3 participants
participants (3)
-
Brian Stansberry -
Claudio Miranda -
Harald Pehl