View Full Version : Data Secutiry - Filtering Data
Dec 27th, 2004, 09:56 PM
My doubt is about protecting data.
Is it possible to use Acegi to verify if a principal has rights to see just some parts of a XML file.
'myuser' can see just tags that start with 'A'
We have a original XML file:
<Before> Some other Data </Before>
And the filtering the rights, the user will se this data:
Dec 28th, 2004, 03:09 PM
Acegi Security doesn't currently provide XML filtering capabilities.
You'd probably be best off generating objects from your unfiltered XML, and then returning a Collection of these from a services layer method. Acegi Security offers a BasicAclEntryAfterInvocationCollectionFilteringPro vider which could then be used to filter elements.
There are other ways as well. You could write a parser which returns just the authorised XML elements, with that parser operating similar to AbstractSecurityInterceptor. For instance, it would ensure the ContextHolder-held Authentication is valid, maintain an ObjectDefinitionSource equivalent, pass to an AccessDecisionManager to decide whether a given XML element can be seen, and generate the resulting XML accordingly.
Another way might be to use XSL transformations, with the execution of each transformation protected by standard method security.
What are you actually trying to achieve by the XML filtering?
Dec 29th, 2004, 09:52 AM
In fact my needs, I think, can be adjusted to a data collection.
What I really need is:
- Data must be filtered with some Regex pattern.
The idea is that some users can view data based on some patterns.
- Data must be filtered based on a Object "property"
The ideia is that some users can view data when "X" property = "SomeData".
- And the Data filtering, can be a bombination of the above.
And it is not clear to me yet how can I do this using Acegi, I'm not developing yet, now i' m just desinging the solution, and I need to understand how can i do this with Acegi to architect all that I need (including interfaces, classes, database schema, etc...)
Dec 30th, 2004, 12:01 AM
Acegi Security has an AfterInvocationManager which can mutate the object returned from a method invocation. You could achieve your goals using that. Check the reference guide (at http://acegisecurity.sourceforge.net) to learn more about how it works.
AfterInvocationManager is typically used with AclManager, which provides "domain object instance" access control lists (ACLs). This is used with the majority of enterprise application data, as domain objects usually correspond to database rows and have identifiers (typically the RDBMS PK). These identifiers form a reference (often the classname + ":" + the primary key - though it's pluggable) the ACLs can be stored against.
The cleanest architectural approach is to never enforce security on XML at all. By all means use it for inter-system transfer, but don't try to filter it for security etc. In practical terms that means:
* For XML you receive, parse the XML into actual domain objects as soon as possible. Persist the domain objects. Generate a corresponding ACL record when the domain objects get persisted. This then allows AclManager to be used with Acegi Security's standard domain object instance security services.
* For XML you generate, use ORM to convert database rows into actual domain objects, then perform ACL security on the domain object Collections. Finally, generate the XML you need from the filtered Collections. This uses AclManager as it was intended.
I don't know the nature of your XML, but generally speaking either of the two approaches above are best practise. I would try to resist having security operating on XML solely via regular expressions or alike, as if the format of the XML changes, or it gets encrypted etc, things will eventually break. It will also be much harder to maintain - like mixing business logic with JSP. It's neater to separate things into appropriate single-purpose layers, so you have an XmlToObjectCollection class, an ObjectCollectionToXml class, and leave security to work with the Collections such classes produce or consume.
Powered by vBulletin® Version 4.2.1 Copyright © 2013 vBulletin Solutions, Inc. All rights reserved.