Well, Spring Security implements ACL;
http://docs.spring.io/spring-security/site/docs/3.0.x/reference/domain-acls.html
> On 7 Jul 2016, at 09:42, Lenny Primak <[email protected]> wrote:
>
> The tricky thing is to figure out what the common feature set actually is
> (i.e. to design it or take already existing design)
> Is there another framework that you know of or any existing project that
> implements this already?
> If this was such a desirable feature for lots of people, it would be hard to
> believe that this wasn’t already implemented somewhere.
>
>> On Jul 7, 2016, at 3:39 AM, Richard Adams <[email protected]> wrote:
>>
>> Yes, I take your point - Shiro has all the Core features you need to get
>> started, it’s conciseness is one of its main attractions, and there’s
>> certainly a strong argument to avoid feature bloat and unnecessary
>> complexity.
>> But, perhaps it is the case, that if many Shiro users are independently
>> having to extend Shiro to obtain additional similar functionality, then
>> there is a case for considering adding to Shiro.
>> Richard
>>> On 7 Jul 2016, at 09:26, Lenny Primak <[email protected]> wrote:
>>>
>>> My sentiments exactly.
>>>
>>> There are a lot of SNACs (shiny new ACronyms) popping up every few months
>>> that “some other framework” may have that are “missing” from Shiro,
>>> like many variants of **BAC (which are very much too vaguely defined, and
>>> not in any way standard)
>>> All of this can easily be solved by a few lines of custom code (in custom
>>> realm etc.)
>>> You can’t possibly chase all those vague acronyms and succeed.
>>>
>>> Saying that, I am not opposed to adding some sort of additional abstraction
>>> layer for **BAC, but it has to be well defined.
>>>
>>> Here is what I see as viable options:
>>> - Write an implementation yourself on top of Shiro, get traction in the
>>> wild, and then contribute it to Shiro, if still makes sense.
>>> - Point out specific code / features / documentation in another framework
>>> that implements your feature that has traction in the industry,
>>> i.e. has proven useful in the wild, and propose inclusion of such specific
>>> functionality in Shiro.
>>>
>>>> On Jul 7, 2016, at 3:02 AM, Richard Bradley <[email protected]>
>>>> wrote:
>>>>
>>>> Could you explain what the benefit of this is over just implementing those
>>>> restrictions in plain old Java code directly?
>>>>
>>>> Each of the use cases you have given could be translated into plain old
>>>> Java code more or less 1-1 and the resulting code would be:
>>>> 1. simpler
>>>> 2. more maintainable
>>>> 3. more accessible to newcomers (no new language needs to be learnt)
>>>> 4. benefit from IDE support and static analysis support
>>>> 5. likely more reliable (there are fewer moving parts; no AOP framework is
>>>> needed etc.; no chance of bugs in the implementation of
>>>> @RequiresAttributes or misunderstandings in its usage)
>>>> 6. easier to test
>>>>
>>>> The only downside I can see is that it might be slightly harder to
>>>> statically verify that a developer has remembered to address security (in
>>>> the proposed version you might be able to write a unit tests that asserts
>>>> that all relevant methods have a non-empty "@RequiresAttributes"
>>>> annotation).
>>>>
>>>> Here are the examples from below rewritten in POJ:
>>>>
>>>> Assume the following helper code is imported in each case:
>>>>
>>>> public class AuthenticationHelper {
>>>> public static void assertAuth(bool ok) {
>>>> if (!ok) {
>>>> throw new AuthenticationException("Insufficient permissions");
>>>> }
>>>> }
>>>>
>>>> public static User currentUser() {
>>>> // create a domain-specific User class from Shiro's
>>>> SecurityUtils.getSubject()
>>>> }
>>>> }
>>>>
>>>> Example of use case #1:
>>>>
>>>> public class ProfileEditor {
>>>>
>>>> // all users implicitly have permission to edit their own profile,
>>>> // so don't need RequiresPermissions, but we do need to check
>>>> // that the profile belongs to this user
>>>> public void store(Profile userProfile) {
>>>> assertAuth(currentUser().id == userProfile.userId);
>>>>
>>>> // TODO: store the changes
>>>> }
>>>>
>>>> }
>>>>
>>>> Example of use case #2:
>>>>
>>>> public class Project {
>>>> List<String> getMemberIds() {
>>>> // TODO: return list of member ids in this project
>>>> }
>>>>
>>>> // the user has role "project manager" with a "settings:edit" permission
>>>> // BUT... it's only for this project, not for all projects!
>>>> @RequiresPermissions("settings:edit")
>>>> public void editSettings(String key, String newValue) {
>>>> assertAuth(getMemberIds().contains(currentUser().id));
>>>>
>>>> // TODO: change the setting
>>>> }
>>>>
>>>> }
>>>>
>>>> Example of use case #3:
>>>>
>>>> public class ClassifiedDocumentRepository {
>>>>
>>>> @RequiresPermissions("documents:store")
>>>> public void storeDocument(@Map("document") Document doc) {
>>>> assertAuth(currentUser().clearanceLevel >= document.clearanceLevel);
>>>> // TODO: store the document
>>>> }
>>>>
>>>> // applying access control on return value here with special variable
>>>> $return
>>>> @RequiresPermissions("documents:retrieve")
>>>> public Document retrieveDocument(String documentId) {
>>>> // TODO: find the document and its metadata
>>>>
>>>> Document document = ...
>>>>
>>>> assertAuth(currentUser().clearanceLevel >= document.clearanceLevel);
>>>> return document;
>>>> }
>>>>
>>>>
>>>> }
>>>>
>>>> Best,
>>>>
>>>>
>>>> Rich
>>>>
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: jbuhacoff [mailto:[email protected]]
>>>> Sent: 07 July 2016 05:19
>>>> To: [email protected]
>>>> Subject: Attribute-based access control
>>>>
>>>> Hi, I've been using Shiro for a couple of years now in various projects
>>>> with annotations and the wildcard permission syntax. Now I have a new
>>>> requirement for ABAC, and I think it should be possible to add this
>>>> capability to Shiro.
>>>> I have a proposal below, and wanted to get some comments. If there's
>>>> interest, I would develop it myself and contribute the code &
>>>> documentation.
>>>>
>>>> Here are some use cases:
>>>>
>>>> 1. a "my profile" or "my settings" feature: user should be able to edit
>>>> own things but not everything in the table.
>>>>
>>>> 2. project or organization based permissions: user should be able to read
>>>> documents in a project while user is associated with the project or team,
>>>> possibly combined with a general "can read documents" permission.
>>>>
>>>> 3. clearance level: user has a "can read documents" permission but this
>>>> needs to be matched with the user's clearance level and the document's
>>>> clearance level.
>>>>
>>>> I see attribute-based access control as being a nice complement and
>>>> orthogonal to the permission-based access control. A given method could
>>>> be annotated with either one or both together to achieve the right level
>>>> of control.
>>>>
>>>> My proposal is to add a new annotation @RequiresAttributes and to let
>>>> its
>>>> value be a boolean expression to be evaluated. Of course the expression
>>>> will need to be able to refer to the current user, the object in question,
>>>> and maybe even other things like the time of day, the https client
>>>> certificate, or whatever. Getting these bits of info into the context of
>>>> the expression language would be a combination of three things: 1) the
>>>> realm can set some context when the user is authenticated based on
>>>> information available at that time (user attributes, connection
>>>> attributes, etc.) , 2) there could be generic "attribute injectors" like
>>>> for calendar/time, system properties, or other things that are neither
>>>> user nor object in question;
>>>> 3) a new @Map annotation that can be applied to method parameters in
>>>> order to give them a specific name in the expression.
>>>>
>>>> Also there is a special case when we might want to apply attribute-based
>>>> permissions on the return value of a method. For this we have another
>>>> annotation @RequiresAttributesOnReturn which would be applied with around
>>>> advice, calling proceed() and then checking permissions using the return
>>>> value of the original method bound to a special variable $return.
>>>>
>>>> Both @RequiresAttributes and @RequiresAttributesOnReturn would have
>>>> corresponding methods that could be called directly from anywhere in the
>>>> code in order to perform the same evaluation without annotations.
>>>>
>>>> Special variable $this would be available to expressions annotated on
>>>> instance methods.
>>>>
>>>> Variables and methods of objects would be accessible via dot notation,
>>>> with automatic use of bean-style "getter" methods when they exist.
>>>>
>>>> In all the following examples, $user is a variable bound by the
>>>> authentication realm to a User object with methods String getId() and
>>>> Integer getClearanceLevel().
>>>>
>>>> Example of use case #1:
>>>>
>>>> public class ProfileEditor {
>>>>
>>>> // all users implicitly have permission to edit their own profile,
>>>> // so don't need RequiresPermissions, but we do need to check
>>>> // that the profile belongs to this user
>>>> @RequiresAttributes("$user.id = $profile.userId")
>>>> public void store(@Map("profile") Profile userProfile) {
>>>> // TODO: store the changes
>>>> }
>>>>
>>>> }
>>>>
>>>> Example of use case #2:
>>>>
>>>> public class Project {
>>>> List<String> getMemberIds() {
>>>> // TODO: return list of member ids in this project
>>>> }
>>>>
>>>> // the user has role "project manager" with a "settings:edit" permission
>>>> // BUT... it's only for this project, not for all projects!
>>>> // also special variable $this refers to enclosing class instance
>>>> @RequiresPermissions("settings:edit")
>>>> @RequiresAttributes("$this.memberIds.contains($user.id)")
>>>> public void editSettings(String key, String newValue) {
>>>> // TODO: change the setting
>>>> }
>>>>
>>>> }
>>>>
>>>> Example of use case #3:
>>>>
>>>> public class ClassifiedDocumentRepository {
>>>>
>>>> @RequiresPermissions("documents:store")
>>>> @RequiresAttributes("$user.clearanceLevel >= $document.clearanceLevel")
>>>> public void storeDocument(@Map("document") Document doc) {
>>>> // TODO: store the document
>>>> }
>>>>
>>>> // applying access control on return value here with special variable
>>>> $return
>>>> @RequiresPermissions("documents:retrieve")
>>>> @RequiresAttributesOnReturn("$user.clearanceLevel >=
>>>> $return.clearanceLevel")
>>>> public Document retrieveDocument(String documentId) {
>>>> // TODO: find the document and its metadata
>>>> return document;
>>>> }
>>>>
>>>>
>>>> }
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> View this message in context:
>>>> http://shiro-user.582556.n2.nabble.com/Attribute-based-access-control-tp7581093.html
>>>> Sent from the Shiro User mailing list archive at Nabble.com.
>>>>
>>>> Richard Bradley
>>>> Tel : 020 7485 7500 ext 3230 | Fax : 020 7485 7575
>>>>
>>>> softwire
>>>> Sunday Times Best Small Companies - UK top 25 six years running
>>>> Web : www.softwire.com<http://www.softwire.com/> | Follow us on Twitter :
>>>> @SoftwireUK<https://twitter.com/SoftwireUK>
>>>> Addr : 110 Highgate Studios, 53-79 Highgate Road, London NW5 1TL
>>>> Softwire Technology Limited. Registered in England no. 3824658. Registered
>>>> Office : Gallery Court, 28 Arcadia Avenue, Finchley, London. N3 2FG
>>>>
>>>
>>
>
