4:06 a.m.
Access Control List - each node to be protected
------------------------------------------------
Key: JBRULES-428
URL: http://jira.jboss.com/jira/browse/JBRULES-428
Project: JBoss Rules
Issue Type: Sub-task
Security Level: Public (Everyone can see)
Components: drools-brms
Reporter: Michael Neale
Assigned To: Michael Neale
Rule nodes (at least) need to have an ACL: what groups can access it in what capacity.
First need to have a structure for ACLs to be stored.
They should be tied to user groups/roles, not individual logins.
JAAS should provide the user name and the users context (group membership) I believe.
When there is an ACL, it must be checked to see if the user (via their group membership)
can do one of the following:
Edit, change status, view, delete.
If they can't view, ideally it will not be shown in any "lists", but if that
is not feasable, it would be acceptable to list it, but not show the contents.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
10:38 a.m.
New subject: [JBoss JIRA] Commented: (JBRULES-428) Access Control List - each node to be protected
[ http://jira.jboss.com/jira/browse/JBRULES-428?page=comments#action_12341332 ]
Michael Neale commented on JBRULES-428:
---------------------------------------
NOTE: reading the JCR spec, you can assign permissions to individual nodes, so I guess we
should use that, then the JCR container will enforce it. Also, the query API will also
respect it. If this is that case, it would be better to use the out of the box stuff then
re-implementing it. Refer to 6.6.1.2 of the JCR spec, and also 6.9.
Some custom work may need to be done to setup the credentials mapping.
Access Control List - each node to be protected
------------------------------------------------
Key: JBRULES-428
URL: http://jira.jboss.com/jira/browse/JBRULES-428
Project: JBoss Rules
Issue Type: Sub-task
Security Level: Public(Everyone can see)
Components: drools-brms
Reporter: Michael Neale
Assigned To: Michael Neale
Rule nodes (at least) need to have an ACL: what groups can access it in what capacity.
First need to have a structure for ACLs to be stored.
They should be tied to user groups/roles, not individual logins.
JAAS should provide the user name and the users context (group membership) I believe.
When there is an ACL, it must be checked to see if the user (via their group membership)
can do one of the following:
Edit, change status, view, delete.
If they can't view, ideally it will not be shown in any "lists", but if
that is not feasable, it would be acceptable to list it, but not show the contents.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
10:40 a.m.
New subject: [JBoss JIRA] Updated: (JBRULES-428) Access Control List - each node to be protected
[ http://jira.jboss.com/jira/browse/JBRULES-428?page=all ]
Michael Neale updated JBRULES-428:
----------------------------------
Description:
Rule nodes (at least) need to have an ACL: what groups can access it in what capacity.
First need to have a structure for ACLs to be stored.
They should be tied to user groups/roles, not individual logins.
JAAS should provide the user name and the users context (group membership) I believe.
When there is an ACL, it must be checked to see if the user (via their group membership)
can do one of the following:
Edit, change status, view, delete.
If they can't view, ideally it will not be shown in any "lists", but if that
is not feasable, it would be acceptable to list it, but not show the contents.
Will need to be able to set permission from within an admin facility of the application.
was:
Rule nodes (at least) need to have an ACL: what groups can access it in what capacity.
First need to have a structure for ACLs to be stored.
They should be tied to user groups/roles, not individual logins.
JAAS should provide the user name and the users context (group membership) I believe.
When there is an ACL, it must be checked to see if the user (via their group membership)
can do one of the following:
Edit, change status, view, delete.
If they can't view, ideally it will not be shown in any "lists", but if that
is not feasable, it would be acceptable to list it, but not show the contents.
Access Control List - each node to be protected
------------------------------------------------
Key: JBRULES-428
URL: http://jira.jboss.com/jira/browse/JBRULES-428
Project: JBoss Rules
Issue Type: Sub-task
Security Level: Public(Everyone can see)
Components: drools-brms
Reporter: Michael Neale
Assigned To: Michael Neale
Rule nodes (at least) need to have an ACL: what groups can access it in what capacity.
First need to have a structure for ACLs to be stored.
They should be tied to user groups/roles, not individual logins.
JAAS should provide the user name and the users context (group membership) I believe.
When there is an ACL, it must be checked to see if the user (via their group membership)
can do one of the following:
Edit, change status, view, delete.
If they can't view, ideally it will not be shown in any "lists", but if
that is not feasable, it would be acceptable to list it, but not show the contents.
Will need to be able to set permission from within an admin facility of the application.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
2:51 p.m.
New subject: [JBoss JIRA] Assigned: (JBRULES-428) Access Control List - each node to be protected
[ http://jira.jboss.com/jira/browse/JBRULES-428?page=all ]
Fernando Meyer reassigned JBRULES-428:
--------------------------------------
Assignee: Fernando Meyer (was: Michael Neale)
Access Control List - each node to be protected
------------------------------------------------
Key: JBRULES-428
URL: http://jira.jboss.com/jira/browse/JBRULES-428
Project: JBoss Drools
Issue Type: Sub-task
Security Level: Public(Everyone can see)
Components: drools-brms
Reporter: Michael Neale
Assigned To: Fernando Meyer
Rule nodes (at least) need to have an ACL: what groups can access it in what capacity.
First need to have a structure for ACLs to be stored.
They should be tied to user groups/roles, not individual logins.
JAAS should provide the user name and the users context (group membership) I believe.
When there is an ACL, it must be checked to see if the user (via their group membership)
can do one of the following:
Edit, change status, view, delete.
If they can't view, ideally it will not be shown in any "lists", but if
that is not feasable, it would be acceptable to list it, but not show the contents.
Will need to be able to set permission from within an admin facility of the application.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
5:54 p.m.
New subject: [JBoss JIRA] Commented: (JBRULES-428) Access Control List - each node to be protected
[ http://jira.jboss.com/jira/browse/JBRULES-428?page=comments#action_12399384 ]
Michael Neale commented on JBRULES-428:
---------------------------------------
I think we need to link this to another JIRA for role based access:
http://wiki.jboss.org/wiki/Wiki.jsp?page=RulesRepositoryRoleAuthorization
Access Control List - each node to be protected
------------------------------------------------
Key: JBRULES-428
URL: http://jira.jboss.com/jira/browse/JBRULES-428
Project: JBoss Drools
Issue Type: Sub-task
Security Level: Public(Everyone can see)
Components: drools-brms
Reporter: Michael Neale
Assigned To: Fernando Meyer
Rule nodes (at least) need to have an ACL: what groups can access it in what capacity.
First need to have a structure for ACLs to be stored.
They should be tied to user groups/roles, not individual logins.
JAAS should provide the user name and the users context (group membership) I believe.
When there is an ACL, it must be checked to see if the user (via their group membership)
can do one of the following:
Edit, change status, view, delete.
If they can't view, ideally it will not be shown in any "lists", but if
that is not feasable, it would be acceptable to list it, but not show the contents.
Will need to be able to set permission from within an admin facility of the application.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
6:08 p.m.
New subject: [JBoss JIRA] Updated: (JBRULES-428) Access Control List - each node to be protected
[ http://jira.jboss.com/jira/browse/JBRULES-428?page=all ]
Fernando Meyer updated JBRULES-428:
-----------------------------------
Description:
Rule nodes (at least) need to have an ACL: what groups can access it in what capacity.
First need to have a structure for ACLs to be stored.
They should be tied to user groups/roles, not individual logins.
JAAS should provide the user name and the users context (group membership) I believe.
When there is an ACL, it must be checked to see if the user (via their group membership)
can do one of the following:
Edit, change status, view, delete.
If they can't view, ideally it will not be shown in any "lists", but if that
is not feasable, it would be acceptable to list it, but not show the contents.
Will need to be able to set permission from within an admin facility of the application.
see http://wiki.jboss.org/wiki/Wiki.jsp?page=RulesRepositoryRoleAuthorization for more
details
was:
Rule nodes (at least) need to have an ACL: what groups can access it in what capacity.
First need to have a structure for ACLs to be stored.
They should be tied to user groups/roles, not individual logins.
JAAS should provide the user name and the users context (group membership) I believe.
When there is an ACL, it must be checked to see if the user (via their group membership)
can do one of the following:
Edit, change status, view, delete.
If they can't view, ideally it will not be shown in any "lists", but if that
is not feasable, it would be acceptable to list it, but not show the contents.
Will need to be able to set permission from within an admin facility of the application.
Access Control List - each node to be protected
------------------------------------------------
Key: JBRULES-428
URL: http://jira.jboss.com/jira/browse/JBRULES-428
Project: JBoss Drools
Issue Type: Sub-task
Security Level: Public(Everyone can see)
Components: drools-brms
Reporter: Michael Neale
Assigned To: Fernando Meyer
Rule nodes (at least) need to have an ACL: what groups can access it in what capacity.
First need to have a structure for ACLs to be stored.
They should be tied to user groups/roles, not individual logins.
JAAS should provide the user name and the users context (group membership) I believe.
When there is an ACL, it must be checked to see if the user (via their group membership)
can do one of the following:
Edit, change status, view, delete.
If they can't view, ideally it will not be shown in any "lists", but if
that is not feasable, it would be acceptable to list it, but not show the contents.
Will need to be able to set permission from within an admin facility of the application.
see http://wiki.jboss.org/wiki/Wiki.jsp?page=RulesRepositoryRoleAuthorization for more
details
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
6:14 p.m.
New subject: [JBoss JIRA] Commented: (JBRULES-428) Access Control List - each node to be protected
[ http://jira.jboss.com/jira/browse/JBRULES-428?page=comments#action_12399385 ]
Michael Neale commented on JBRULES-428:
---------------------------------------
Note: user accounts (user names) are defined OUTSIDE of the application. User groups, and
membership, will need to be part of the application (I think).
Access Control List - each node to be protected
------------------------------------------------
Key: JBRULES-428
URL: http://jira.jboss.com/jira/browse/JBRULES-428
Project: JBoss Drools
Issue Type: Sub-task
Security Level: Public(Everyone can see)
Components: drools-brms
Reporter: Michael Neale
Assigned To: Fernando Meyer
Rule nodes (at least) need to have an ACL: what groups can access it in what capacity.
First need to have a structure for ACLs to be stored.
They should be tied to user groups/roles, not individual logins.
JAAS should provide the user name and the users context (group membership) I believe.
When there is an ACL, it must be checked to see if the user (via their group membership)
can do one of the following:
Edit, change status, view, delete.
If they can't view, ideally it will not be shown in any "lists", but if
that is not feasable, it would be acceptable to list it, but not show the contents.
Will need to be able to set permission from within an admin facility of the application.
see http://wiki.jboss.org/wiki/Wiki.jsp?page=RulesRepositoryRoleAuthorization for more
details
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
6:29 p.m.
New subject: [JBoss JIRA] Commented: (JBRULES-428) Access Control List - each node to be protected
[ http://jira.jboss.com/jira/browse/JBRULES-428?page=comments#action_12399386 ]
Fernando Meyer commented on JBRULES-428:
----------------------------------------
We can use the get users from the JAAS what do you think?
Access Control List - each node to be protected
------------------------------------------------
Key: JBRULES-428
URL: http://jira.jboss.com/jira/browse/JBRULES-428
Project: JBoss Drools
Issue Type: Sub-task
Security Level: Public(Everyone can see)
Components: drools-brms
Reporter: Michael Neale
Assigned To: Fernando Meyer
Rule nodes (at least) need to have an ACL: what groups can access it in what capacity.
First need to have a structure for ACLs to be stored.
They should be tied to user groups/roles, not individual logins.
JAAS should provide the user name and the users context (group membership) I believe.
When there is an ACL, it must be checked to see if the user (via their group membership)
can do one of the following:
Edit, change status, view, delete.
If they can't view, ideally it will not be shown in any "lists", but if
that is not feasable, it would be acceptable to list it, but not show the contents.
Will need to be able to set permission from within an admin facility of the application.
see http://wiki.jboss.org/wiki/Wiki.jsp?page=RulesRepositoryRoleAuthorization for more
details
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
6:41 p.m.
New subject: [JBoss JIRA] Commented: (JBRULES-428) Access Control List - each node to be protected
[ http://jira.jboss.com/jira/browse/JBRULES-428?page=comments#action_12399387 ]
Anil Saldhana commented on JBRULES-428:
---------------------------------------
What you need to do is sync up with Stefan about the new Instance Based ACL
implementation.
Access Control List - each node to be protected
------------------------------------------------
Key: JBRULES-428
URL: http://jira.jboss.com/jira/browse/JBRULES-428
Project: JBoss Drools
Issue Type: Sub-task
Security Level: Public(Everyone can see)
Components: drools-brms
Reporter: Michael Neale
Assigned To: Fernando Meyer
Rule nodes (at least) need to have an ACL: what groups can access it in what capacity.
First need to have a structure for ACLs to be stored.
They should be tied to user groups/roles, not individual logins.
JAAS should provide the user name and the users context (group membership) I believe.
When there is an ACL, it must be checked to see if the user (via their group membership)
can do one of the following:
Edit, change status, view, delete.
If they can't view, ideally it will not be shown in any "lists", but if
that is not feasable, it would be acceptable to list it, but not show the contents.
Will need to be able to set permission from within an admin facility of the application.
see http://wiki.jboss.org/wiki/Wiki.jsp?page=RulesRepositoryRoleAuthorization for more
details
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
6:57 p.m.
New subject: [JBoss JIRA] Commented: (JBRULES-428) Access Control List - each node to be protected
[ http://jira.jboss.com/jira/browse/JBRULES-428?page=comments#action_12399388 ]
Fernando Meyer commented on JBRULES-428:
----------------------------------------
Jackrabbit SimpleAccessManager class only supports three access levels: anonymous,
normal, and system. I think I will need to implement a custom AccessManager class to get
more advanced AC, implementing the AccessManager interface I think we can internally use
the jboss security api to control that.
@Anil, I've already spoken with Stefan about that, I'm taking a look into
security's api
Access Control List - each node to be protected
------------------------------------------------
Key: JBRULES-428
URL: http://jira.jboss.com/jira/browse/JBRULES-428
Project: JBoss Drools
Issue Type: Sub-task
Security Level: Public(Everyone can see)
Components: drools-brms
Reporter: Michael Neale
Assigned To: Fernando Meyer
Rule nodes (at least) need to have an ACL: what groups can access it in what capacity.
First need to have a structure for ACLs to be stored.
They should be tied to user groups/roles, not individual logins.
JAAS should provide the user name and the users context (group membership) I believe.
When there is an ACL, it must be checked to see if the user (via their group membership)
can do one of the following:
Edit, change status, view, delete.
If they can't view, ideally it will not be shown in any "lists", but if
that is not feasable, it would be acceptable to list it, but not show the contents.
Will need to be able to set permission from within an admin facility of the application.
see http://wiki.jboss.org/wiki/Wiki.jsp?page=RulesRepositoryRoleAuthorization for more
details
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
7:41 p.m.
New subject: [JBoss JIRA] Commented: (JBRULES-428) Access Control List - each node to be protected
[ http://jira.jboss.com/jira/browse/JBRULES-428?page=comments#action_12399389 ]
Michael Neale commented on JBRULES-428:
---------------------------------------
@Anil : how does relate to any Seam security api that was in the works ?
Access Control List - each node to be protected
------------------------------------------------
Key: JBRULES-428
URL: http://jira.jboss.com/jira/browse/JBRULES-428
Project: JBoss Drools
Issue Type: Sub-task
Security Level: Public(Everyone can see)
Components: drools-brms
Reporter: Michael Neale
Assigned To: Fernando Meyer
Rule nodes (at least) need to have an ACL: what groups can access it in what capacity.
First need to have a structure for ACLs to be stored.
They should be tied to user groups/roles, not individual logins.
JAAS should provide the user name and the users context (group membership) I believe.
When there is an ACL, it must be checked to see if the user (via their group membership)
can do one of the following:
Edit, change status, view, delete.
If they can't view, ideally it will not be shown in any "lists", but if
that is not feasable, it would be acceptable to list it, but not show the contents.
Will need to be able to set permission from within an admin facility of the application.
see http://wiki.jboss.org/wiki/Wiki.jsp?page=RulesRepositoryRoleAuthorization for more
details
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
8:19 p.m.
New subject: [JBoss JIRA] Updated: (JBRULES-428) Access Control List - each node to be protected
[ http://jira.jboss.com/jira/browse/JBRULES-428?page=all ]
Mark Proctor updated JBRULES-428:
---------------------------------
Assignee: Michael Neale (was: Fernando Meyer)
Access Control List - each node to be protected
------------------------------------------------
Key: JBRULES-428
URL: http://jira.jboss.com/jira/browse/JBRULES-428
Project: JBoss Drools
Issue Type: Sub-task
Security Level: Public(Everyone can see)
Components: drools-brms
Reporter: Michael Neale
Assigned To: Michael Neale
Rule nodes (at least) need to have an ACL: what groups can access it in what capacity.
First need to have a structure for ACLs to be stored.
They should be tied to user groups/roles, not individual logins.
JAAS should provide the user name and the users context (group membership) I believe.
When there is an ACL, it must be checked to see if the user (via their group membership)
can do one of the following:
Edit, change status, view, delete.
If they can't view, ideally it will not be shown in any "lists", but if
that is not feasable, it would be acceptable to list it, but not show the contents.
Will need to be able to set permission from within an admin facility of the application.
see http://wiki.jboss.org/wiki/Wiki.jsp?page=RulesRepositoryRoleAuthorization for more
details
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
11:38 p.m.
New subject: [JBoss JIRA] Closed: (JBRULES-428) Access Control List - each node to be protected
[
https://jira.jboss.org/jira/browse/JBRULES-428?page=com.atlassian.jira.pl...
]
Michael Neale closed JBRULES-428.
---------------------------------
Fix Version/s: 5.0.0.M3
Resolution: Done
Access Control List - each node to be protected
------------------------------------------------
Key: JBRULES-428
URL: https://jira.jboss.org/jira/browse/JBRULES-428
Project: JBoss Drools
Issue Type: Sub-task
Security Level: Public(Everyone can see)
Components: drools-guvnor
Reporter: Michael Neale
Assignee: Michael Neale
Fix For: 5.0.0.M3
Rule nodes (at least) need to have an ACL: what groups can access it in what capacity.
First need to have a structure for ACLs to be stored.
They should be tied to user groups/roles, not individual logins.
JAAS should provide the user name and the users context (group membership) I believe.
When there is an ACL, it must be checked to see if the user (via their group membership)
can do one of the following:
Edit, change status, view, delete.
If they can't view, ideally it will not be shown in any "lists", but if
that is not feasable, it would be acceptable to list it, but not show the contents.
Will need to be able to set permission from within an admin facility of the application.
see http://wiki.jboss.org/wiki/Wiki.jsp?page=RulesRepositoryRoleAuthorization for more
details
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
2:52 a.m.
New subject: [JBoss JIRA] Updated: (JBRULES-428) Access Control List - each node to be protected
[
https://jira.jboss.org/browse/JBRULES-428?page=com.atlassian.jira.plugin....
]
Toni Rikkola updated JBRULES-428:
---------------------------------
Parent: (was: JBRULES-684)
Issue Type: Feature Request (was: Sub-task)
Access Control List - each node to be protected
------------------------------------------------
Key: JBRULES-428
URL: https://jira.jboss.org/browse/JBRULES-428
Project: Drools
Issue Type: Feature Request
Security Level: Public(Everyone can see)
Components: drools
Reporter: Michael Neale
Assignee: Michael Neale
Fix For: drools-5.0.0.M3
Rule nodes (at least) need to have an ACL: what groups can access it in what capacity.
First need to have a structure for ACLs to be stored.
They should be tied to user groups/roles, not individual logins.
JAAS should provide the user name and the users context (group membership) I believe.
When there is an ACL, it must be checked to see if the user (via their group membership)
can do one of the following:
Edit, change status, view, delete.
If they can't view, ideally it will not be shown in any "lists", but if
that is not feasable, it would be acceptable to list it, but not show the contents.
Will need to be able to set permission from within an admin facility of the application.
see http://wiki.jboss.org/wiki/Wiki.jsp?page=RulesRepositoryRoleAuthorization for more
details
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
5163
days inactive
6702
days old
13 comments
6 participants
participants (6)
-
Anil Saldhana (JIRA) -
Fernando Meyer (JIRA)
-
Mark Proctor (JIRA)
-
Michael Neale (JIRA) -
Michael Neale (JIRA)
-
Toni Rikkola (JIRA)