Surety is performing system maintenance this weekend. Electronic date stamps on new Prior Art Database disclosures may be delayed.
Browse Prior Art Database

Fine-grained flow access control for J2EE-based workflow systems

IP.com Disclosure Number: IPCOM000010837D
Original Publication Date: 2003-Jan-24
Included in the Prior Art Database: 2003-Jan-24
Document File: 2 page(s) / 34K

Publishing Venue



In this article, we show how to protect the access to business processes in an EJB based workflow system by combining the J2EE security mechanisms with the generation of business process facade EJBs and the use of special role patterns.

This text was extracted from a PDF file.
At least one non-text object (such as an image or picture) has been suppressed.
This is the abbreviated version, containing approximately 60% of the total text.

Page 1 of 2

Fine-grained flow access control for J2EE-based workflow systems

  An EJB-based workflow system is using an EJB interface (stateless session EJB) to execute and control flows identified by a unique name or ID (flow name/ID). The rights to execute and control a specific flow depend on the flow referenced by that name/ID. On the other hand, the J2EE security model only allows to define authorization rights for an entire EJB or certain EJB methods. For defining authorization rights on a per-flow base, the J2EE security capabilities are not sufficient.

    This paper describes how to apply J2EE security to objects different from EJBs (in this example, flows) by wrapping them with a thin EJB layer ("EJB facade"). This effectively allows to use J2EE security roles to efficiently protect flows without having to code an individual EJB for each flow -- as the "facade" EJBs can be automatically generated as part of the flow's deployment.

    The solution is to create an EJB ("EJB facade") for each flow that is to be protected using J2EE security. This EJB externalizes all the original methods of the workflow system, but allows their application only to the associated flow. The association itself can be done as appropriate, e.g., using a naming scheme, or explicit reference. Now, the "facade" EJB can be protected using normal J2EE mechanisms, associating roles with either the entire EJB or individual methods of it, and associating users with those roles.

    In the example below, WF_abc...