El sáb, 17-04-2010 a las 09:40 -0400, Mauricio Salatino escribió:
All the authorization part in my opinion should be left outside of
the
framework scope. Because it always depends on business needs.
The way that it's handled in Drools Flow and in jBPM 3.2.x it's a good
approach.
jBPM 3 does not "handle" the requirement It just ignores it. There is
even an "AuthorizationService" there, which never got implemented, yet
the idea was to have a permission-based scheme similar to the Java
platform's. Indeed, security should be configurable to business needs,
where the default is "allow all" in the absence of a security policy.
That does not mean the BPM engine cannot do anything but sidestep the
problem.
I was sufficiently impressed with the security extension to jBPM 4
presented in the InfoQ article below to push forward security (actually,
just authorization; authentication would still be delegated to the
application) as a feature of jBPM 5.
http://www.infoq.com/articles/authorizing_process_access
-Alejandro