The Workspace User role ony controls whether the user is allowed to use Workspace or not. A user will only be able to Start a Process in Workspace if they a) are a Workspace User and b) the process security settings allow them to by having the INVOKE_PERM enabled. The INVOKE_PERM setting is usually controlled from within Application Management area in the Adminui and would be set per process to define who is allowed to invoke (start) that service (process). Take a look at your processes and see if they are defined for the All Principals group having the INVOKE_PERM as this is one way in which everybody can start a process.
I'm unfamiliar with the Services User role but if it sounds like maybe this has the INVOKE_PERM so this could be why all your users can start processes, presuming they are all in this role.
But however the INVOKE_PERM priviledge is being granted, it is not via the Workspace User role.
Hope that helps.
Thanks Jon, that was definitely helpful. I understand that this is how it works in ES1, however I am now using ES2 and am having trouble getting this same setup to work. Do you know if there is any difference with ES2?
I have a user WITHOUT the 'invoke' permission, and for the service itself there is no principals listed under the Security tab of the Service in the admin UI. However, as this user i am still able to see the process and invoke it through the task manager endpoint.
There is no difference to the security model between ES1 and ES2. It is a bug if any user with just the Workspace User role can even see a TaskManager Endpoint, let alone invoke it. Also, please confirm that this user isn't a member of any Groups or Roles that may have implicit permission to invoke all services, i.e. Administrators or Service Users
If you user truly doesn't have the invoke permission, can you describe how the user was created (local or ldap sync) and how the process was created in ES2 (a migration from ES1, an import of an ES1 lca, or created in ES2 workbench)?
It should work the same as in ES.
In fact I just did a test. I created a new user and assigned him the Workspace User role and that user couldn't see any of my processes in Workspace.
Then I went to one of my process and added the INVOKE_PERM permission to that user (under Security) and the user was able to see that one process, but not the other ones.
If it doesn't work for you, it could be because the group "All User in XXX domain" has some right associated to it and all the users within that group inherit the rights.
To be absolutely sure, create a new group and add a new user with only Workspace User role and test with that user and see if you get the same results.
Thanks Jasmin... I in fact get the expected result when i created a new user with Workspace_User role and put them in a new group, they are unable to see my process.
So this works in the DefaultDom... however, in my real world scenario I am still having issues:
-we are doing LDAP sync to bring in the users and groups from a separate domain, and in this case, the users with only Workspace_User role can still invoke the task manager endpoint
-the process was created in Workbench ES2
I was hoping to find that the user was inheriting the services role from a group they were in or something, but it doesn't seam to be the case. I have a user who only has Workspace_User role, and the group they are in also only has Workspace_User role. They are not in any Administrator or Services groups or roles. I even checked the Services_User role users... and my user is not listed there or in any group listed there.
And again it works ok when i set up the basic example in DefaultDom... but not when I try using the users in our synched domain. Is there anywhere else you could think of that they would be inheriting these permissions from?
I did another test where I sychronized with my Active Directory and it still worked for me.
What LDAP server are you using?
we're using Windows Active Directory (i believe windows 2003)
I also found that with the default/sample setup (with the sample users John Jacobs, Kara Bowman, etc) and without touching any of their roles and without our LDAP sync, users like John Jacobs can invoke my task manager endpoint without being in the Services User role or any Admin role.
I've installed the sample and I get the same results as you!
I do get this error in the application server log:
2010-02-26 14:02:24,953 WARN [com.adobe.idp.common.errors.exception.IDPLoggedException] UserM:GENERIC_WARNING: [Thread Hashcode: 1039020657] com.adobe.idp.common.errors.exception.IDPLoggedException| [AuthenticationManagerBean] errorCode:12817 errorCodeHEX:0x3211 message:The user kbowman is marked as Obsolete
Do you get the same?
I could be a bug with obsolete users.
1 person found this helpful
Just noticed something else.
The users kbowman and jjacobs have the Workspace User and Content Space user role.
If you remove the Content Space user role, it works like it's supposed to.
The reason is the Content Space user role has the Service Invoke permission, which give the users access to invoke any service in LiveCycle.
I'm still not clear why the users from your AD can see everything.
Again you're sure they don't have any roles other than Workspace User?
One last thing.....
I just want to make sure that security is enabled for that service.
I'm probably stating the obvious, but just want to make sure.
This solves my problem! So... I never thought to look to see if Contentspace User role had the Services Invoke permission, ugh!
PS the ones in our AD also have both Workspace User and Contentspace User roles... so it was the same problem. I tested it out and now have the expected results.
Thanks a lot for your help.