I have a multi-part, possibly confusing question... it's been a while
since I've dug in to the Authorization bundle, so it's taking me a bit
to remember how it all works. Bear with me as I struggle to make sense
of my thoughts, here :)
The majority of the code that I'm writing in my system uses a call to
the documentSession.IsAllowed method to check and see if the
AuthorizationUser has permissions for the Activity specified. This has
been working wonderfully for us, no problem. I'm expanding my app's
authorization to make use of tags now and I'm wondering:
Does the documentSession.IsAllowed method account for Tags on document
permissions, role permissions, and user permissions?
For example:
If I have Bob assigned to the Manager role. The Manager role is
assigned a permission to allow a "Review" operation, with a Tag of
"ReadyForReview" on that permission. How do I make a call to
documentSession.isAllowed in a way that verifies that Bob can "Review"
things that are tagged "ReadyForReview" ?
I realize that I may be asking the wrong question and/or looking at
this from the wrong perspective. If I am going about this wrong,
please let me know.
The end goal is really to say "Can Bob review this assignment?" Where
an Assignment is a document in RavenDB that may or may not have a
"ReadyForReview" tag. Bob should only be allowed to review assignments
that have the "ReadyForReview" tag. I would like to have a method that
gives me a boolean value telling me if Bob can review that document.
Derick,
In addition to simply IsAllowed, you also have IsOperationAllowedOnDocument.
That allows you to ask security questions about a specific document instance, not just globally.
Related
Given something simple like this:
<Dashboard v-if="$store.getters.ui.user.role == 'staff'/>
<Dashboard v-if="$store.getters.ui.user.role == 'manager'/>
... what is the best practice for defending against someone changing user.role from 'staff' to 'manager' in the browser.
(Of course, data is loaded from the server based on role here, so at best the curious user will see an empty and slightly broken interface, but better if they see nothing at all). Other than obfuscation of the rather obv's user.role=='staff', I can't see any way around it.
There is no way to prevent a user from being able to change the client-side code provided to him. The solution you mentioned is the right approach. Never trust the user with any sensitive data unless verified by your server.
This means that while a user with bad intentions might be able to change his role to "manager" and thereby get access to the dashboard (or even remove the if-statement only rendering the Dashboard conditionally - the code is there), the dashboard he sees cannot contain any sensitive data only supposed to be visible to users with a "manager" role.
The key is not providing the user any data he is not supposed to see in the first place, not obfuscate the data passed in hopes the user won't notice. You are not protecting against the average user but rather somebody who knows how to code and has the intention of breaking your application. Obfuscated code is a small hurdle and not sufficient to prevent attackers from seeing and understanding the underlying logic.
Out-of-the-box, an Alfresco user can read a document based on:
The document's permissions
The user's role
The user's groups
Whether the user owns the document or not
Maybe some other factors I forgot?
Now, I want to add a new factor: Whether the document is currently part of a workflow.
Alfresco's permissionDefinitions.xml allows me to define permissions based on authorities such as ROLE_LOCK_OWNER etc, but it does not seem to be the right place to add permission conditions.
I guess I will have to write some Java source code, but I am not sure what classes are responsible for this, and whether there is an Alfresco way to customize them?
So, I assume you want to somehow have nodes that are attached to a workflow have different access rights? You need to think about the behavior you want in all of the UIs and protocols you are exposing (e.g. share, WebDAV, CIFS, FTP, etc.).
If you want to set a permission on a node, you can do that via JavaScript as well as Java (See http://docs.alfresco.com/5.2/references/API-JS-setPermission.html and http://docs.alfresco.com/5.2/references/dev-services-permission.html). As was mentioned in one of the comments, you can also get the number of active workflows on a node by referencing the activeWorkflows property in JavaScript (http://docs.alfresco.com/5.2/references/API-JS-ScriptNode.html) or in Java
Depending on the specifics, I might implement this in different ways, but if all you want to do is have the permission change, you could just update it at the beginning and end of your workflow with a simple javascript call. The only thing bad about that is that it doesn't take into consideration the workflow getting canceled. You could also create a policy/behavior on an aspect you attach or even have a rule or job run that updates content based on the activeWorkflows values.
I'm trying to programmatically determine whether the current user has certain permissions on a given Active Directory object (specifically in this case, I'm trying to determine whether the user has the "Send As" permission for another Exchange user or distribution list object).
I already figured out how to access the ntSecurityDescriptor attribute using ADSI: I can enumerate the ACEs in the IADsSecurityDescriptor's DiscretionaryACL property. But:
How do I determine from that data whether the "Send As"-permission is explicitly allowed or denied for a trustee?
How do I discover this when the permission has been granted indirectly via group membership? Do I really have to parse the effective permissions myself by (recursively) checking all groups the user is a member of? Surely there must be an API for that task...
FWIW, I'm coding in Delphi (i.e. native Win32 code) using the ActiveDs.dll typelibrary, so .NET-specific solutions won't really help me much unless their source code gives me clues to how to do the same thing in native code. The same goes for PowerShell.
Before anyone starts: I already know about the PR_EMS_AB_PUBLIC_DELEGATES and PR_EMS_AB_PUBLIC_DELEGATES_BL_O Extended MAPI properties. However, this is not what I'm after. These properties refer to the "Send on behalf of"-right (a.k.a. delegates), not the "Send As" permission, which is quite a different thing.
Here's the MSDN article that explains - http://msdn.microsoft.com/en-us/library/windows/desktop/ms675580(v=VS.85).aspx. There is an attached sample that shows how to call the API.
I recently heard term 'Writable API' which is totally new for me. Can anyone explain what does it mean?
A publicly writable API is an API that allows anyone to attach meta-data to objects in the owner's database without changing the original content.
For example, take this object: http://twitter.com/#!/MarsPhoenix/status/1917793215. It is a tweet from the Pheonix Mars Lander.
The tweet is owned by Twitter. But what if I want to tag it and share those tags with the world?
If Twitter opened a writeble API, I could add my own data to this tweet. Say I add the tags "mars" and "nasa" to this object, they would be stored as devon/tag:mars and devon/tag:nasa in their database. If user Bob added a tag of "phoenix", it would be stored as bob/tag:phoenix in Twitter's database.
Now we can both share our tags with the world without overwriting any of Twitter's or each other's data.
Here is a good blog post explaining the concept:
http://blogs.fluidinfo.com/fluidinfo/2011/02/14/what-is-a-writable-api/
I wrote the article #Devon linked to, so agree with him :-) Though I'd change his "without changing the original content" to also say that the addition to the data also doesn't require the permission of the original app either (APIs are in a way largely about permission - they're designed to let you do things, but also sharply limit what you can do).
As a concrete illustration of #Devon's example of putting metadata onto tweets, here's how you can do it with Fluidinfo: http://blogs.fluidinfo.com/fluidinfo/2009/12/01/putting-metadata-onto-tweets-with-fluiddb/
We've also posted some writable API examples, for Boing Boing and Union Square Ventures. See http://blogs.fluidinfo.com/fluidinfo/2011/01/27/how-we-made-an-api-for-boingboing-in-an-evening/ and http://blogs.fluidinfo.com/fluidinfo/2011/02/15/how-i-made-a-writable-api-for-union-square-ventures-in-an-hour/
We have a couple more nice examples coming out this week at the LAUNCH conference in SF.
Hope that helps!
Terry Jones
A Writable API would be an API that allows you to write data to the target system/platform rather than a Read-Only API.
For example, StackOverflow/StackExchange provides a Read-Only API whereas the Twitter API is Writable.
I first encountered the concept of lazy registration the Ajax Patterns site, where they define it as accumulating "bits of information about the user as they interact, with formal registration occurring later on." I'm looking at doing something similar for my website, but I'd like to know a little bit more about best practices before I start implementing it. My site is about web development, but general best practices are great too. How have you implemented lazy registration on your sites or projects? Where have you seen it in the wild? What do you like or dislike about it?
Have a look at this vid, a very good overview of the lazy registration pattern:
http://www.90percentofeverything.com/2009/03/16/signup-forms-must-die-heres-how-we-killed-ours/
I say this not as a person who has designed such a site before, but as a person that might visit that site. :)
With that said, the thing that I would be the most concerned about is knowing what kind of information is being collected about me. And I think that there should be an option to opt out of collecting the information and instead entering it all during formal registration.
But other than that, if it makes registering for a website easier, I'd be all for it. I leave 9 out of 10 sites that require me to register to do stuff.
One way that I was thinking about implementing this is when users leave blog comments. A common Wordpress format is to allow site visitors to comment as long as they leave a name and an email address. If I followed a similar pattern and then after they submit their comment, ask them if they would also like to register by having username and password inputs right there, with their email pre-filled in the email address input. There would also be a message saying that if they choose not to register at that time, their email address won't be saved (other than in association with the blog comment). If you think of something to add to this, leave a comment.
Use OpenID.
I hate it when I have to enter the same data over and over again, and to think of new passwords because you (read: the website) likely store them as plaintext.
Oh, and please don't require me to give you a fake email.
Like this way www.soup.io/signup or the email way www.posterous.com or www.tripit.com