Thanks for your reply. Our organization has decided not to pursue Syncope but I would like to remain involved and examine these issues. My thinking is that one would associate one or more workflows to a resource. The resource would know which workflow to launch based on attributes of the prospective user. Perhaps an overall workflow, similar to what is there, would orchestrate the others and allow CRUD operations on the user to proliferate to the other workflows as well as to resources to which the user is provisioned.
Wrt our problem with the workflow, I wonder if there is some setting on the connector that would make it provision the user based on the fact that the SyncopeUser object exists, rather than looking for an authorization. Thanks and regards, Dave. -----Original Message----- From: Francesco Chicchiriccò [mailto:ilgro...@apache.org] Sent: Friday, March 29, 2013 11:00 AM To: dev@syncope.apache.org Subject: Re: Activiti approval fails on deny On 29/03/2013 14:01, Walker, David R. (JMD) wrote: > Here is the bpmn we're using. Corrected for roles meant that the roles in > the default bpmn were not created at installation so I created new ones and > modified the bpmn to use the new role IDs. Pretty trivial and I shouldn't > have mentioned it. Also, it looks like we're on 1.0.6. I will try to reproduce the problem you are experiencing with embedded environment [3] and let you know but... after Easter ;-) > A comment on the workflow: the use of a single workflow to describe the > entire user lifecycle may not be scalable. I am curious as to why that > approach was taken. Is there a way to define additional processes and bind > them to resources and organizations? We are in a large organization composed > of many thousands of personnel residing in many tens if not hundreds of > independent and semi-independent components. Each of these has at least one > and sometimes many different approaches (procedures) to grant/remove access > to systems and facilities and permissions (authorized to carry a gun, for > example). This is not practical using the approach Syncope has taken, unless > I'm missing something. I would think that the ability to bind separate > workflows to assigned resources would introduce the flexibility we need to > implement processes that handle access to a resource for our organization. Well, first of all let me say that you organization is challenging. The workflow approach that you outline above is quite different from the one implemented in 1.0.X and 1.1.X - I'd be happy if you can start a [DISCUSS] thread about this topic on this mailing list, but nevertheless this is not going to change anytime soon. In principle, however, one could write a custom workflow adapter [4] for the workflow engine that an organization like yours might have already in place. Regards. > -----Original Message----- > From: Francesco Chicchiriccò [mailto:ilgro...@apache.org] > Sent: Friday, March 29, 2013 4:07 AM > To: dev@syncope.apache.org > Subject: Re: Activiti approval fails on deny > > Hi David, > you will find my replies embedded below. > > Regards. > > On 28/03/2013 21:23, Walker, David R. (JMD) wrote: >> When using the default workflow (corrected for roles) > I guess you are running 1.1.0-SNAPSHOT: correct? What does "corrected for > roles" mean? Can you provide your userWorkflow.bpmn20.xml (or relevant > fragments) via http://apaste.info/? > >> the approval task will accept a response of "No" but the user is provisioned >> to the denied resource anyway. What is the correct approach to denying >> access to one resource but granting access to others? > Since the approval is currently implemented - in the default workflow > definition, at least - as a whole acceptance / reject, you would need to > implement this requirement by providing your own service tasks (e.g. > Java classes similar to [1] - in the hypotesis you are on 1.1.0-SNAPSHOT). > >> Scenario: >> >> 1. Admin creates a new user and with a resource of "Active >> Directory-IP" and a role of "Active Directory User". >> 2. The role routes the action to a user task. >> 3. Another participant, the approver, picks up the user task on her >> ToDo list and claims it. >> 4. The approver selects "No" on the Boolean >> 5. The task completes >> 6. The user is provisioned to Active Directory anyway. >> >> Attempts to modify the workflow to delete the syncopeUser on a denial fail >> in that the task ignores the "No" selection and remains on the ToDo list for >> the assignee. > In the default workflow definition [2], a "No" moves the user in a 'Rejected' > state and no propagation occurs at all: I think then that the problems you > are observing are highly dependent on the customization introduced. I need > more details about these for being able to provide some hints. > > [1] > https://svn.apache.org/repos/asf/syncope/trunk/core/src/main/java/org/ > apache/syncope/core/workflow/user/activiti/task/Create.java > [2] > https://cwiki.apache.org/confluence/display/SYNCOPE/Default+Workflow [3] https://cwiki.apache.org/confluence/display/SYNCOPE/Run+Syncope+in+embedded+mode [4] https://cwiki.apache.org/confluence/display/SYNCOPE/Choose+workflow+engine -- Francesco Chicchiriccò ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member http://people.apache.org/~ilgrosso/
