You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by bu...@apache.org on 2006/03/04 02:00:15 UTC
DO NOT REPLY [Bug 38849] New: - [Shale] Support for fine grained security on navigation
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG�
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=38849>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND�
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=38849
Summary: [Shale] Support for fine grained security on navigation
Product: Struts
Version: Nightly Build
Platform: Other
OS/Version: other
Status: NEW
Severity: enhancement
Priority: P2
Component: Shale
AssignedTo: dev@struts.apache.org
ReportedBy: craig.mcclanahan@sun.com
Conversations on the Struts user mailing list today highlight the potential for
a Shale value add with regards to authorization. It was noted that container
managed security can protect the incoming form submits, but does not protect
navigation to an arbitrary page (because constraints are only applied on the
initial submit, not on RequestDispatcher.forward() calls used to implement the
navigation). It would be interesting for Shale to offer a customized navigation
handler that would allow limitation of navigation to specified view identifiers
based on request.isUserInRole().
As a further generalization, it would be useful to present this capability as a
general purpose plugin architecture, where the application could provide any
sort of fine grained access control it wanted ("only managers can navigate to
the salary details page, and only for their own employees"). A built in plugin
that supported container managed security could be a "reference implementation"
of this featue.
--
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
DO NOT REPLY [Bug 38849] - [Shale] Support for fine grained security on navigation
Posted by bu...@apache.org.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG�
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=38849>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND�
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=38849
------- Additional Comments From gvanmatre@comcast.net 2006-03-04 05:31 -------
This sounds similar to something I've seen in a financial record keeping
system. They defined a hierarchy of permissions on resources that were data
centric.
This was an interesting design because it was difference than your standard
groups, users and roles. It added a OO spin that was also relational.
You created a generalization template defining the order of evaluation of
rules assigned to context state. In the snippet below (stylized for JSF and
XML), the individual would override the group, group override the profile and
the providing company would be the most general.
<generalization id="TOP_MENU">
<context id="PROV_COMPANY" expr="#{sessionScope['prov']}" level="0"/>
<context id="PROFILE" expr="#{sessionScope['prof']}" level="2"/>
<context id="GROUP" expr="#{sessionScope['grp']}" level="4"/>
<context id="INDV" expr="#{requestScope['ind_id']}" level="6"/>
</generalization>
Define arbitrary resources associated with visual widgets, transactions or
operations.
<resources id="view_balance" description="Participant Balance"/>
<resources id="transfer_history" description="Transfer History"/>
Define rules that associate a resource with a relationship used in its
evaluation based on a know data state.
<rule resourceId="view_balance" generalizationId="TOP_MENU"
contextId="PROV_COMPANY" contextRuleValue="ABC LLC" status="OFF" />
<rule resourceId="view_balance" generalizationId="TOP_MENU" contextId="GROUP"
contextRuleValue="1234" status="OFF"/>
<rule resourceId="view_balance" generalizationId="TOP_MENU" contextId="GROUP"
contextRuleValue="4321" status="ON"/>
Pseudo code:
//find the relationship used to evaluation the status of a resource
Generalization gen = Factory.getGeneralization("TOP_MENU");
//populate the relationship with context state data
GenContext genContext = new GenContext(gen, facesContext);
//find all rules for a resource ordered by the relationship
ResourceRules rules = Factory.getResourceRules("view_balance", gen);
// evaluation the status of a resource based on the current state and the
relationships
rules.evaluate(genContext)
--
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
DO NOT REPLY [Bug 38849] - [Shale] Support for fine grained security on navigation
Posted by bu...@apache.org.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG�
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=38849>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND�
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=38849
------- Additional Comments From niallp@apache.org 2006-03-04 03:08 -------
For reference, the user thread is here:
http://www.nabble.com/Shale-Container-Managed-Security-t1221102.html
+1 to plugability and something that isn't necessarily tied to container
managed security. In our organization we not only protect actions/pages but
data as well. Below are examples of the types of requirements we have - not so
that any solution to this caters for them, just that it doesn't limit/prevent
custom implementations that do being plugged in.
For example we have a structure that comprises: Group, Companies, region, sub
region, portfolio and investment. Access can be controlled at any level
(portfolio and above). So for example a user might be given access
to "Northern Region's data".
We also have other data structures that cut accross the "corporation
structure" - e.g. banks, partners, solicitors and agents that can also be used
to control access (e.g. a user might be given access to Bank "XYZ"'s data).
The same user in the application can have different "data level" access for
different functions - so for example they might be able to see certian pages
for "Northern region", but for other pages be restricted to the "North West
sub region".
As well as the above we also have the ability to "disable" access at various
levels - individual action/pages, users, roles or any of the above "data"
levels (e.g. we can enable/disable "Northern Region").
--
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org