[jBPM Development] - jBPM5 Roadmap
by Kris Verlaenen
Kris Verlaenen [http://community.jboss.org/people/KrisVerlaenen] modified the document:
"jBPM5 Roadmap"
To view the document, visit: http://community.jboss.org/docs/DOC-15344
--------------------------------------------------------------
This document describes a proposal for the jBPM5 roadmap, based on the feedback of the community on the suggested features in the jBPM5 request for comments (http://community.jboss.org/docs/DOC-15172). It will constantly be updated with the necessary details (feature lists, dates) based on community feedback, etc.
More features will be added in the following releases to work towards our full vision.
Feedback on the roadmap is welcome on the jbpm-dev(a)lists.jboss.org (mailto:jbpm-dev@lists.jboss.org) mailing list. If you want to help out (big or small, from new features or patches to documentation or testing), that's the place to go as well ! Or come have a chat at #jbpm on irc.codehaus.org.
*DISCLAIMER:* this roadmap is not considered to be finalized yet, it is a proposal that might still be changed according to customer / community feedback
*jBPM 5.1*
Target date: May 2nd, 2011 *
*
*New BPMN 2.0 Eclipse editor*
A new BPMN 2.0 Eclipse editor will be created, supporting full the BPMN2 syntax and most of the BPMN2 constructs. It will also allow you to constrain which elements and attributes should be shown (for example to create a jBPM 5 profile that only shows the elements and attributes as supported by jBPM 5).
*Designer*
The web-based designer (based on Oryx) will be updated to support full round-tripping and include support for custom jBPM5 attributes. This will allow you to create executable BPMN2 using the Designer only (without requiring filling in the execution details in Eclipse.
*Web service integration*
Improved web service integration (using pluggable work items) and UI enhancements to enhance service orchestration capabilities
*Repository of domain-specific services*
The set of out-of-the-box services will be extended and includes a repository where these definitions can be downloaded from.
*Business Activity Monitoring (BAM)*
Extend BAM reporting / direct intervention capabilities
h1. History
History of roadmap for released version
*jBPM 5.0
*
The first release of jBPM5 will include support for business processes in their entire life cycle (modeling, deployment, execution, monitoring) with the following key characteristics:
* native BPMN2 engine
* light-weight, embeddable or "as a service"
* higher-level, domain-specific processes
* strong rule and event processing integration
* web tooling for more business-oriented users
As requested by most community members, the first release will focus on the core of the various components, with simple tooling associated with it. The core can then be extended with more advanced features and tooling in the following releases.
Clean, separate, simple *knowledge-oriented API* for setting up sessions, loading process definitions, executing process instances, event listeners, etc.
*Core process engine using BPMN 2.0* process definition format. The specification document and associated XSD definition files can be found here (http://www.omg.org/spec/BPMN/2.0/). The engine will (at least) support the "common executable" subclass as defined in the specification (a minimal set of elements / attributes for specifying executable processes), but in a Java developer context (meaning supporting Java domain model and expression language). The specification defines that the following elements (and associated attributes) are part of this subclass:
| sequenceFlow (unconditional) | id, (name), sourceRef, targetRef |
| sequenceFlow (conditional) | id, name, sourceRef, targetRef, conditionExpression |
| sequenceFlow (default) | id, name, sourceRef, targetRef, default |
| subProcess (expanded) | id, name, flowElement, loopCharacteristics,** boundaryEventRefs |
| exclusiveGateway | id, name, gatewayDirection (only converging and diverging), default |
| parallelGateway | id, name, gatewayDirection (only converging and diverging) |
| startEvent (None) | id, name |
| endEvent (None) | id, name |
| eventBasedGateway | id, name, gatewayDirection, eventGatewayType |
| userTask | id, name, renderings, implementation, resources, ioSpecification, dataInputAssociations, dataOutputAssociations, loopCharacteristics, boundaryEventRefs |
| serviceTask | id, name, implementation, operationRef, ioSpecification, dataInputAssociations, dataOutputAssociations, loopCharacteristics, boundaryEventRefs |
| callActivity | id, name, calledElement, ioSpecification, dataInputAssociations, dataOutputAssociations, loopCharacteristics, boundaryEventRefs |
| dataObject | id, name, isCollection, itemSubjectRef |
| textAnnotation | id, text |
| dataAssociation | id, name, sourceRef, targetRef, assignment |
| messageStartEvent | id, name, messageEventDefinition (either ref or contained), dataOutput, dataOutputAssociations |
| messageEndEvent | id, name, messageEventDefinition, (either ref or contained), dataInput, dataInputAssociations |
| terminateEndEvent | (Terminating trigger in combination with one of the other end events) |
| Catching message IE | id, name, messageEventDefinition (either ref or contained), dataOutput, dataOutputAssociations |
| Throwing message IE | id, name, messageEventDefinition (either ref or contained), dataInput, dataInputAssociations |
| Catching timer IE | id, name, timerEventDefinition (contained) |
| Boundary error IE | id, name, attachedToRef, errorEventDefinition, (contained or referenced), dataOutput, dataOutputAssociations |
Depending on the progress, additional node types will probably already be supported by that time as well. The list of supported elements and attributes will regularly be updated so you can have a clear idea of what to expect in each release.
The core BPMN2 engine of course includes
* persistence (JPA-based with pluggable variable persistence)
* transaction support
* auditing
* history log
* basic process instance migration
* etc.
Also support for domain-specific nodes and powerful rules integration.
*Human tasks*
Independent human task service for managing human tasks based on the WS-HumanTask specification.
Simple web-based human task web console supporting the task life cycle (claim, start, complete, etc.) and custom task forms.
*Eclipse-based tooling for creating BPMN2 processes*
Eclipse-based plugin that allows developers to graphically create BPMN2 processes, including basic validation, testing and debugging.
*Web-based tooling for creating BPMN2 processes*
We'd like to continue the integration of the web-based BPMN2 editor based on the open-source Oryx editor.
*Process repository*
Knowledge repository for storing process definitions.
Simple web-based repository management console for storing process definitions, versioning, releasing, etc.
*Process management console*
Simple web-based console for starting processes, managing running instances, checking current state of one specific instance, aborting, etc.
*Reporting*
Customizable reports using BIRT
Simple web-based console for viewing real-time reports
*Installation* script (and demo setup)
*Documentation*
*Migration*
Support for migration from jPDL3 (product) and jPDL4 (community), in the form of a semi-automatic, one-shot, user-assisted transformation process to BPMN2 for process definitions and documentation.
--------------------------------------------------------------
Create a new document in jBPM Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=102&co...]
13 years, 2 months
[IronJacamar Development] - Re: IronJacamar RHQ plugin development
by Jesper Pedersen
Jesper Pedersen [http://community.jboss.org/people/jesper.pedersen] created the discussion
"Re: IronJacamar RHQ plugin development"
To view the discussion, visit: http://community.jboss.org/message/591498#591498
--------------------------------------------------------------
Gao, regarding JBJCA-507 - there are a couple of things with the JIRA we need to clear up.
First the WeakReference issue - those are WeakReferences because the management layer can't keep a deployment active. That is the job of the services around that area.
So my guess is that the resource adapter you are using is not fully implemented with the constructs you need for your test case. F.ex. make sure that the ManagedConnectionFactory is used ResourceAdaperAssociation, and the ManagedConnectionFactory is included as a variable in your ConnectionFactory's. The same goes for AdminObject's. If that doesn't help then we need to investigate further why those references are null. You can use the code generator or see the HelloWorld example in order to get started.
It is correct that in some cases the objects will only be used during startup, and hence not valid once management kicks in. In those scenarios we need to back the view (f.ex. ResourceAdapter) with a read-only model based on the metadata (ra.xml / ironjacamar.xml).
So in the end there will a valid view of the deployments without having to construct it - the management layer needs to look at the "live" objects in the container.
Hope this helps !
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/591498#591498]
Start a new discussion in IronJacamar Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
13 years, 2 months
[JBoss AS7 Development] - Management API Security Key Decisions
by Darran Lofthouse
Darran Lofthouse [http://community.jboss.org/people/dlofthouse] modified the document:
"Management API Security Key Decisions"
To view the document, visit: http://community.jboss.org/docs/DOC-16586
--------------------------------------------------------------
h1. Key Decisions
This article tracks the key decisions to be made regarding the security of the management APIs.
h2. Traditional Authentication or Security Tokens
This problem was introduced closely related to authentication caches - without the overhead invovled during authentication this would purely be about personal preferences.
http://community.jboss.org/docs/DOC-16452 Design Consideration - Management API Authentication Caching
The following article highlights some of the advantages and disadvantages of each approach.
http://community.jboss.org/docs/DOC-16584 Management API Security Token vs Per Node Authentication
h3. Decision
|| *Option* || *Comments
* ||
| Traditional Only |
|
| Security Token Only |
|
| Traditional Only then add Secutiry Token Support |
|
h2. Authentication Mechanisms (Server Side)
Regardless of if we stick with traditional authentication or use a security token some form of authentication will still be required first to provide the security token.
The following article discusses these options.
http://community.jboss.org/docs/DOC-16574 Management API Security Authentication Mechanisms
h3. Decision
|| *Option* || *Comment* ||
| Support a simple property file based authentication? |
|
| Support LDAP based authentication? |
|
| Support Database based authentication? |
|
| Support delegate to domain controller type authentication? |
|
h2. Authentication Mechanism (Transport)
The following article explores how exposing our own APIs now gives us some flexibiliy regarding how to handle different authentication mechanisms for the transport.
http://community.jboss.org/docs/DOC-16587 Management API Security Transport Authentication
Essentially we can now dynamically identify one of a number of potential mechanisms from a single request instead of the previous servlet container based approach where you would need to forward to different deployments to use different mechanisms.
h2. Host to Domain Controller Authentication
The following article explores the authentication and establishment of trust between the remote host and the domain controller.
http://community.jboss.org/docs/DOC-16579 Management API Security Host to Domain Controller Security
Essentially the host is just a special type of user, initially no different to any other administrator but at some point when ACLs are defined we can review adding an ACL for 'register host' or something similar.
No decisions here unless there are additional comments?
This does imply that an exposed management API may need to support multiple authentication mechanisms at the protocol level as support certificates for the host to domain controller connection does not nescesarily mean a desire for administrators to also use certificates when they connect.
h2. Configuration Options
The security is going to require additional configuration for the definition, as the only configuration made available so far is which APIs to expose there are no pre-existing placeholders to insert the security configuration.
The following article shows the current configuration.
http://community.jboss.org/docs/DOC-16494 Management API Security Configuration
The following article starts to explore in terms of traditional authentication how this could be defined.
http://community.jboss.org/docs/DOC-16576 Management API Security Possible Configuration Samples
h3. Decision
|| *Option* || *Comment* ||
| Prefer configuration focussed in domain.xml? |
|
| Prefer configuration focussed in host.xml? |
|
h2. Database Connection Pool
We are required to integrate with existing security infrastructure, this means we will need to support a Database login module so we will require connections to the database.
h3. Decision
Who will previde the connection pool?
|| *Option* || *Comment* ||
| Provided by the management security implementation. |
|
| Will be provided as part of another task. |
|
h2. Authorization Checks
At this stage out only requirement is to verify that the user is authenticated, the following raises points to consider regarding how authorization checks will be performed depending on how a request reaches the management API on any host.
http://community.jboss.org/docs/DOC-16583 Management API Security Authorization Responsibility
--------------------------------------------------------------
Comment by going to Community
[http://community.jboss.org/docs/DOC-16586]
Create a new document in JBoss AS7 Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=102&co...]
13 years, 2 months
[JBoss AS7 Development] - Management API Security Transport Authentication
by Darran Lofthouse
Darran Lofthouse [http://community.jboss.org/people/dlofthouse] created the document:
"Management API Security Transport Authentication"
To view the document, visit: http://community.jboss.org/docs/DOC-16587
--------------------------------------------------------------
h1. Transport Authentication
At the tansport level a mechanism is required to recieve the users identity at the server, as we are using the simple HTTP server in addition to the Native API we have greater control of this compared to a JBoss Web style deployment using the web.xml descriptor to define the security constraints.
I propose that we use follow an approach that priorotises the mechanism used to recieve the identify falling back to other mechanisms as needed.
The order would be: -
1. Security Token
2. Username / Password
3. Client Certificate
h3. Security Token
This is the highest priority as if the calling client has passed in a security token the authentication has already occurred so there would be no reason to fall back and repeat.
h3. Username / Password
In terms of HTTP this would be a case of using the credentials passed using BASIC authentication from the client to the server.
The reason this is second and not third is because it will still be likely that SSL is used when username / password authentication is used so detecting a username and password has been sent in the request we can assume the user is deliverately trying to identify themselves with this pair.
h3. Client Certificate
Finally if no security token is provided and no username/pasword is provided we can attempt to use the clients certificate for authentication.
h2. Configuration
Username/Password authentication and client-cert authentication require different approaches to authentication so each will require a custom security domain to be defined.
Instead of adding any additional configuration to control username/password or client-cert authentication we can use the definition or lack of definition of the two domains to identify is username/password or client-cert authentication is supported.
i.e. For username / password authentication to even be considered a security domain for username / password authentication must have been defined - if this domain does not exist then this is not supported.
--------------------------------------------------------------
Comment by going to Community
[http://community.jboss.org/docs/DOC-16587]
Create a new document in JBoss AS7 Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=102&co...]
13 years, 2 months
[JBoss AS7 Development] - Management API Security Key Decisions
by Darran Lofthouse
Darran Lofthouse [http://community.jboss.org/people/dlofthouse] modified the document:
"Management API Security Key Decisions"
To view the document, visit: http://community.jboss.org/docs/DOC-16586
--------------------------------------------------------------
h1. Key Decisions
This article tracks the key decisions to be made regarding the security of the management APIs.
h2. Traditional Authentication or Security Tokens
This problem was introduced closely related to authentication caches - without the overhead invovled during authentication this would purely be about personal preferences.
http://community.jboss.org/docs/DOC-16452 Design Consideration - Management API Authentication Caching
The following article highlights some of the advantages and disadvantages of each approach.
http://community.jboss.org/docs/DOC-16584 Management API Security Token vs Per Node Authentication
h3. Decision
|| *Option* || *Comments
* ||
| Traditional Only |
|
| Security Token Only |
|
| Traditional Only then add Secutiry Token Support |
|
h2. Authentication Mechanisms (Server Side)
Regardless of if we stick with traditional authentication or use a security token some form of authentication will still be required first to provide the security token.
The following article discusses these options.
http://community.jboss.org/docs/DOC-16574 Management API Security Authentication Mechanisms
h3. Decision
|| *Option* || *Comment* ||
| Support a simple property file based authentication? |
|
| Support LDAP based authentication? |
|
| Support Database based authentication? |
|
| Support delegate to domain controller type authentication? |
|
h2. Host to Domain Controller Authentication
The following article explores the authentication and establishment of trust between the remote host and the domain controller.
http://community.jboss.org/docs/DOC-16579 Management API Security Host to Domain Controller Security
Essentially the host is just a special type of user, initially no different to any other administrator but at some point when ACLs are defined we can review adding an ACL for 'register host' or something similar.
No decisions here unless there are additional comments?
This does imply that an exposed management API may need to support multiple authentication mechanisms at the protocol level as support certificates for the host to domain controller connection does not nescesarily mean a desire for administrators to also use certificates when they connect.
h2. Configuration Options
The security is going to require additional configuration for the definition, as the only configuration made available so far is which APIs to expose there are no pre-existing placeholders to insert the security configuration.
The following article shows the current configuration.
http://community.jboss.org/docs/DOC-16494 Management API Security Configuration
The following article starts to explore in terms of traditional authentication how this could be defined.
http://community.jboss.org/docs/DOC-16576 Management API Security Possible Configuration Samples
h3. Decision
|| *Option* || *Comment* ||
| Prefer configuration focussed in domain.xml? |
|
| Prefer configuration focussed in host.xml? |
|
h2. Database Connection Pool
We are required to integrate with existing security infrastructure, this means we will need to support a Database login module so we will require connections to the database.
h3. Decision
Who will previde the connection pool?
|| *Option* || *Comment* ||
| Provided by the management security implementation. |
|
| Will be provided as part of another task. |
|
h2. Authorization Checks
At this stage out only requirement is to verify that the user is authenticated, the following raises points to consider regarding how authorization checks will be performed depending on how a request reaches the management API on any host.
http://community.jboss.org/docs/DOC-16583 Management API Security Authorization Responsibility
--------------------------------------------------------------
Comment by going to Community
[http://community.jboss.org/docs/DOC-16586]
Create a new document in JBoss AS7 Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=102&co...]
13 years, 2 months
[JBoss AS7 Development] - Management API Security Configuration
by Darran Lofthouse
Darran Lofthouse [http://community.jboss.org/people/dlofthouse] modified the document:
"Management API Security Configuration"
To view the document, visit: http://community.jboss.org/docs/DOC-16494
--------------------------------------------------------------
This document is to list the configuration required to secure the management APIs. Some of these tasks may be taken care of within other tasks but this is a general overview.
h3. Overall Domain Management Security
Currently no top level element to hold this although should probably be a child of some 'domain-management' element.
h3. Existing Configuration
Currently the domain management configuration is limited to options to specify which management APIs to expose and for nodes where to locate the domain controller.
h4. Standalone Configuration
For standalone servers the following can be defined within the standalone.xml :-
<management>
<native-api interface="default" port="9999"/>
<http-api interface="default" port="9990"/>
</management>
i.e. At this stage the only configuration is to identify which APIs to expose publicly.
h4. Domain Configuration
For domain deployments the following can be defined in the host.xml :-
<management>
<native-api interface="public" port="9999"/>
<http-api interface="public" port="9990"/>
</management>
i.e. As before the APIs to expose can be defined on a host by host basis.
The node which has the master domain controller can also have the following: -
<domain-controller>
<local/>
</domain-controller>
This is simple as the sole purpose is to indicate that this node manages the domain locally so does not need to work with any remote domain controller.
If the node will use a remote domain controller it may have the following defined instead: -
<domain-controller>
<remote host="127.0.0.1" port="9999"/>
</domain-controller>
This is defining a connection to the native-api of the node with the master domain controller.
At this stage there is no centralised configuration for domain management.
h3. Future Requirements
h4. Authentication (Internal)
The following document contains some information regarding the requirements for the back end authentication to the existing infrastructure: -
http://community.jboss.org/docs/DOC-16574 Management API Security Authentication Mechanisms
The following document then shows a couple of starting points to consider how configuration of the authentication could fit within the three descriptors: -
http://community.jboss.org/docs/DOC-16576 Management API Security Possible Configuration Samples
h4. Host to Domain Controller Communication
I am planning that the hosts are just another type of user when they connect to the domain controller, the following article explorers the options we will support with some initial ideas relating to the configuration.
http://community.jboss.org/docs/DOC-16579 Management API Security Host to Domain Controller Security
--------------------------------------------------------------
Comment by going to Community
[http://community.jboss.org/docs/DOC-16494]
Create a new document in JBoss AS7 Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=102&co...]
13 years, 2 months
[JBoss AS7 Development] - Management API Security Key Decisions
by Darran Lofthouse
Darran Lofthouse [http://community.jboss.org/people/dlofthouse] modified the document:
"Management API Security Key Decisions"
To view the document, visit: http://community.jboss.org/docs/DOC-16586
--------------------------------------------------------------
h1. Key Decisions
This article tracks the key decisions to be made regarding the security of the management APIs.
h2. Traditional Authentication or Security Tokens
This problem was introduced closely related to authentication caches - without the overhead invovled during authentication this would purely be about personal preferences.
http://community.jboss.org/docs/DOC-16452 Design Consideration - Management API Authentication Caching
The following article highlights some of the advantages and disadvantages of each approach.
http://community.jboss.org/docs/DOC-16584 Management API Security Token vs Per Node Authentication
h3. Decision
|| *Option* || *Comments
* ||
| Traditional Only |
|
| Security Token Only |
|
| Traditional Only then add Secutiry Token Support |
|
h2. Authentication Mechanisms (Server Side)
Regardless of if we stick with traditional authentication or use a security token some form of authentication will still be required first to provide the security token.
The following article discusses these options.
http://community.jboss.org/docs/DOC-16574 Management API Security Authentication Mechanisms
h3. Decision
|| *Option* || *Comment* ||
| Support a simple property file based authentication? |
|
| Support LDAP based authentication? |
|
| Support Database based authentication? |
|
| Support delegate to domain controller type authentication? |
|
h2. Host to Domain Controller Authentication
The following article explores the authentication and establishment of trust between the remote host and the domain controller.
http://community.jboss.org/docs/DOC-16579 Management API Security Host to Domain Controller Security
Essentially the host is just a special type of user, initially no different to any other administrator but at some point when ACLs are defined we can review adding an ACL for 'register host' or something similar.
No decisions here unless there are additional comments?
This does imply that an exposed management API may need to support multiple authentication mechanisms at the protocol level as support certificates for the host to domain controller connection does not nescesarily mean a desire for administrators to also use certificates when they connect.
h2. Configuration Options
The security is going to require additional configuration for the definition, as the only configuration made available so far is which APIs to expose there are no pre-existing placeholders to insert the security configuration.
The following article starts to explore in terms of traditional authentication how this could be defined.
http://community.jboss.org/docs/DOC-16576 Management API Security Possible Configuration Samples
h3. Decision
|| *Option* || *Comment* ||
| Prefer configuration focussed in domain.xml? |
|
| Prefer configuration focussed in host.xml? |
|
h2. Database Connection Pool
We are required to integrate with existing security infrastructure, this means we will need to support a Database login module so we will require connections to the database.
h3. Decision
Who will previde the connection pool?
|| *Option* || *Comment* ||
| Provided by the management security implementation. |
|
| Will be provided as part of another task. |
|
h2. Authorization Checks
At this stage out only requirement is to verify that the user is authenticated, the following raises points to consider regarding how authorization checks will be performed depending on how a request reaches the management API on any host.
http://community.jboss.org/docs/DOC-16583 Management API Security Authorization Responsibility
--------------------------------------------------------------
Comment by going to Community
[http://community.jboss.org/docs/DOC-16586]
Create a new document in JBoss AS7 Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=102&co...]
13 years, 2 months
[JBoss AS7 Development] - Management API Security Key Decisions
by Darran Lofthouse
Darran Lofthouse [http://community.jboss.org/people/dlofthouse] modified the document:
"Management API Security Key Decisions"
To view the document, visit: http://community.jboss.org/docs/DOC-16586
--------------------------------------------------------------
h1. Key Decisions
This article tracks the key decisions to be made regarding the security of the management APIs.
h2. Traditional Authentication or Security Tokens
This problem was introduced closely related to authentication caches - without the overhead invovled during authentication this would purely be about personal preferences.
http://community.jboss.org/docs/DOC-16452 Design Consideration - Management API Authentication Caching
The following article highlights some of the advantages and disadvantages of each approach.
http://community.jboss.org/docs/DOC-16584 Management API Security Token vs Per Node Authentication
h3. Decision
|| *Option* || *Comments
* ||
| Traditional Only |
|
| Security Token Only |
|
| Traditional Only then add Secutiry Token Support |
|
h2. Authentication Mechanisms (Server Side)
Regardless of if we stick with traditional authentication or use a security token some form of authentication will still be required first to provide the security token.
The following article discusses these options.
http://community.jboss.org/docs/DOC-16574 Management API Security Authentication Mechanisms
h3. Decision
|| *Option* || *Comment* ||
| Support a simple property file based authentication? |
|
| Support LDAP based authentication? |
|
| Support Database based authentication? |
|
| Support delegate to domain controller type authentication? |
|
h2. Configuration Options
The security is going to require additional configuration for the definition, as the only configuration made available so far is which APIs to expose there are no pre-existing placeholders to insert the security configuration.
The following article starts to explore in terms of traditional authentication how this could be defined.
http://community.jboss.org/docs/DOC-16576 Management API Security Possible Configuration Samples
h3. Decision
|| *Option* || *Comment* ||
| Prefer configuration focussed in domain.xml? |
|
| Prefer configuration focussed in host.xml? |
|
h2. Database Connection Pool
We are required to integrate with existing security infrastructure, this means we will need to support a Database login module so we will require connections to the database.
h3. Decision
Who will previde the connection pool?
|| *Option* || *Comment* ||
| Provided by the management security implementation. |
|
| Will be provided as part of another task. |
|
h2. Authorization Checks
At this stage out only requirement is to verify that the user is authenticated, the following raises points to consider regarding how authorization checks will be performed depending on how a request reaches the management API on any host.
http://community.jboss.org/docs/DOC-16583 Management API Security Authorization Responsibility
--------------------------------------------------------------
Comment by going to Community
[http://community.jboss.org/docs/DOC-16586]
Create a new document in JBoss AS7 Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=102&co...]
13 years, 2 months
[JBoss AS7 Development] - Management API Security Token vs Per Node Authentication
by Darran Lofthouse
Darran Lofthouse [http://community.jboss.org/people/dlofthouse] modified the document:
"Management API Security Token vs Per Node Authentication"
To view the document, visit: http://community.jboss.org/docs/DOC-16584
--------------------------------------------------------------
h1. Token vs Per Node Authentication
For the security of the management APIs we can consider either replicating the authentication mechanism to each node or we can consider implementing a token mechanism where a client can obtain a token that they subsequently embed in each request that can be verified simply to identify the user.
The primary reason for considering this is that authentication can be a slow process when communicating with remote stores of users, if we are considering scenarios where users connect directly to nodes to retrieve runtime state as a perfromance gain we need to ensure that authentication does not erode that gain.
h2. Per Node Authentication
Here the management APIs will be secured so that the user can either authenticate by providing a username and password each time they connect or we will use their certificate used for the SSL connection to identify them.
|| *Advantages* || *Disadvantages* ||
| Uses a form of authentication we have used regularly elsewhere. | An authentication cache will be required on each node, domain wide invalidation requests will be required if any details of the users account changes. |
| User can authenticate in the same way on any node. | Performance hit requiring authentication to be performed on each node the user connect to. |
| Uses standard authentication mechanisms at the protocol level e.g. BASIC | Difficult to pass users identity to different nodes. |
|
|
|
h2. Token Authentication
For this scenario the user will call some form of login operation on the master domain controller, this will perform normal authentication to verify the user and obtain their roles, a token will then be created that contains the users identity, their roles, a created time and an expiration time - this token will then be signed by the master domain controller. On each subsequent request this token will be passed as a part of the request, the signature will be verified as will the two times and then the contained list of roles will be used.
|| *Advantages* || *Disadvantages* ||
| Eliminates the need for an authentication cache as the token is the cache. | Will be a new concept for JBoss AS |
| Performance hit when token is created but after that any node can verify the token using certificates. | Some form of revocation list will be required on each node. i.e. Disallow all tokens for user X created before time Y. (Only required for a comprimised account as for changes such as new roles they can just request a new token) |
| Have a simple artefact that can be passed from node to node to transfer clients identity. | User potentially needs to authenticare on master DC first - although we could have slave DC signed tokens for requests only against that DC. |
|
| Passing the token would be outside of the standard authentication mechanisms at the protocol level. |
--------------------------------------------------------------
Comment by going to Community
[http://community.jboss.org/docs/DOC-16584]
Create a new document in JBoss AS7 Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=102&co...]
13 years, 2 months