[jBPM Development] - Unable to run the business process using JBPM 5.4
by ganesh r
ganesh r [https://community.jboss.org/people/ganesh0902] created the discussion
"Unable to run the business process using JBPM 5.4"
To view the discussion, visit: https://community.jboss.org/message/777659#777659
--------------------------------------------------------------
I have downloaded latest JBPM 5.4 final full installer. After installing in my local machine, developed a business process with human task, start event -> user task -> end event.
To run the business process I have used the following code,
public static final void main(String[] args) throws Exception {
// load up the knowledge base
//startUp();
KnowledgeBase kbase = readKnowledgeBase();
StatefulKnowledgeSession ksession = kbase.newStatefulKnowledgeSession();
HornetQHTWorkItemHandler humanTaskHandler = new HornetQHTWorkItemHandler(
ksession);
humanTaskHandler.setIpAddress("127.0.0.1");
humanTaskHandler.setPort(5445);
ksession.getWorkItemManager().registerWorkItemHandler("Human Task",
humanTaskHandler);
Map<String, Object> params = new HashMap<String, Object>();
params.put("title", "ESS");
params.put("businessKey", "ESS-Key");
// start a new process instance
ksession.startProcess("com.sample.bpmn.hello",params);
}
private static KnowledgeBase readKnowledgeBase() throws Exception {
KnowledgeBuilder kbuilder = KnowledgeBuilderFactory.newKnowledgeBuilder();
kbuilder.add(ResourceFactory.newClassPathResource("sample.bpmn"), ResourceType.BPMN2);
return kbuilder.newKnowledgeBase();
}
But it is throwing the following exception,
0 21/11 03:07:38,030[main] ERROR service.hornetq.HornetQTaskClientConnector.connect - Unable to connect to server using configuration org-hornetq-core-remoting-impl-netty-NettyConnectorFactory?port=5445&host=127-0-0-1
Exception in thread "main" org.jbpm.workflow.instance.WorkflowRuntimeException: [com.sample.bpmn.hello:1 - User Task:4] -- Could not connect task client: on ip: 127.0.0.1 - port: 5445
at org.jbpm.workflow.instance.impl.NodeInstanceImpl.trigger(NodeInstanceImpl.java:132)
at org.jbpm.workflow.instance.impl.NodeInstanceImpl.triggerNodeInstance(NodeInstanceImpl.java:279)
at org.jbpm.workflow.instance.impl.NodeInstanceImpl.triggerCompleted(NodeInstanceImpl.java:238)
at org.jbpm.workflow.instance.node.ActionNodeInstance.triggerCompleted(ActionNodeInstance.java:55)
at org.jbpm.workflow.instance.node.ActionNodeInstance.internalTrigger(ActionNodeInstance.java:51)
at org.jbpm.workflow.instance.impl.NodeInstanceImpl.trigger(NodeInstanceImpl.java:126)
at org.jbpm.workflow.instance.impl.NodeInstanceImpl.triggerNodeInstance(NodeInstanceImpl.java:279)
at org.jbpm.workflow.instance.impl.NodeInstanceImpl.triggerCompleted(NodeInstanceImpl.java:238)
at org.jbpm.workflow.instance.node.StartNodeInstance.triggerCompleted(StartNodeInstance.java:49)
at org.jbpm.workflow.instance.node.StartNodeInstance.internalTrigger(StartNodeInstance.java:41)
at org.jbpm.workflow.instance.impl.NodeInstanceImpl.trigger(NodeInstanceImpl.java:126)
at org.jbpm.ruleflow.instance.RuleFlowProcessInstance.internalStart(RuleFlowProcessInstance.java:35)
at org.jbpm.process.instance.impl.ProcessInstanceImpl.start(ProcessInstanceImpl.java:194)
at org.jbpm.workflow.instance.impl.WorkflowProcessInstanceImpl.start(WorkflowProcessInstanceImpl.java:309)
at org.jbpm.process.instance.ProcessRuntimeImpl.startProcessInstance(ProcessRuntimeImpl.java:170)
at org.jbpm.process.instance.ProcessRuntimeImpl.startProcess(ProcessRuntimeImpl.java:140)
at org.drools.common.AbstractWorkingMemory.startProcess(AbstractWorkingMemory.java:1098)
at org.drools.impl.StatefulKnowledgeSessionImpl.startProcess(StatefulKnowledgeSessionImpl.java:320)
at com.sample.ProcessMain.main(ProcessMain.java:35)
Caused by: java.lang.IllegalArgumentException: Could not connect task client: on ip: 127.0.0.1 - port: 5445
at org.jbpm.process.workitem.wsht.GenericHTWorkItemHandler.connect(GenericHTWorkItemHandler.java:158)
at org.jbpm.process.workitem.wsht.GenericHTWorkItemHandler.executeWorkItem(GenericHTWorkItemHandler.java:180)
at org.drools.process.instance.impl.DefaultWorkItemManager.internalExecuteWorkItem(DefaultWorkItemManager.java:70)
at org.jbpm.workflow.instance.node.WorkItemNodeInstance.internalTrigger(WorkItemNodeInstance.java:107)
at org.jbpm.workflow.instance.impl.NodeInstanceImpl.trigger(NodeInstanceImpl.java:126)
... 18 more
Before running the business process I have started h2, jboss and task service using ant start.demo
Do I'm missing anything here?
--------------------------------------------------------------
Reply to this message by going to Community
[https://community.jboss.org/message/777659#777659]
Start a new discussion in jBPM Development at Community
[https://community.jboss.org/choose-container!input.jspa?contentType=1&con...]
11 years, 5 months
[JBoss AS 7 Development] - writing own standalone module that needs legacy log4j support
by John Mazzitelli
John Mazzitelli [https://community.jboss.org/people/mazz] created the discussion
"writing own standalone module that needs legacy log4j support"
To view the discussion, visit: https://community.jboss.org/message/777275#777275
--------------------------------------------------------------
This is yet another log4j thread - however, I think its different than most that have been posted - at least I can't find the answer to my specific use case - so don't roll your eyes just yet :)
I am not writing an EAR, WAR, whatever. I am writing a standalone module (it has a Main-Class in it - its just like what the org.jboss.as.cli module does) and I am deploying it as just a module. I start the server via something like "java -jar jboss-modules.jar -mp <module paths> org.my.module" (this is similar to how the jboss CLI script starts the CLI)
However, my module code is using some legacy libraries that use both commons-logging with log4j underneath (there is a log4j.xml that I want to be used to configure the logging).
I do NOT get any ClassNotFound or similar errors, the code runs "ok" - only, I do not see any of log messages coming out in the console or the file (I have both appenders defined in log4j.xml).
In my modules.xml, I do have a dependency on modules org.apache.commons.logging, org.apache.log4j, org.jboss.logmanager and org.jboss.logging. My module does NOT have any of those jars inside of it (that is, my module does not contain the log4j.jar or the commons-logging.jar - since I have a dependency declared for them, I did not put them in my module).
Does this make sense? Any ideas on how I get this to work? Oh, and where exactly is log4j getting is configuration if not from my module's own logj4.xml?
--------------------------------------------------------------
Reply to this message by going to Community
[https://community.jboss.org/message/777275#777275]
Start a new discussion in JBoss AS 7 Development at Community
[https://community.jboss.org/choose-container!input.jspa?contentType=1&con...]
11 years, 5 months
Re: [jboss-dev-forums] [JBoss AS 7 Development] - Design of AS7 multi-JSF feature
by Pavol Pitonak
Pavol Pitonak [https://community.jboss.org/people/ppitonak] commented on the document
"Design of AS7 multi-JSF feature"
To view all comments on this document, visit: https://community.jboss.org/docs/DOC-47689#comment-11160
--------------------------------------------------
Hi Stan,
I built latest AS from you branch on Github but when I deploy a RichFaces app, I get this error:
Unable to process annotations for url, vfs:/content/simpleapp.war/WEB-INF/lib/richfaces-components-ui-4.3.0-20121120.101714-220.jar/META-INF/faces-config.xml. Reason: java.util.zip.ZipException: zip file is empty
13:42:47,713 SEVERE [javax.enterprise.resource.webcontainer.jsf.config] (MSC service thread 1-5) : java.util.zip.ZipException: zip file is empty
Is it ready for deploying apps?
--------------------------------------------------
11 years, 5 months
[JBoss Messaging Development] - clustering problem with JBoss Messaging in JBoss 5.1
by Nitesh Mehta
Nitesh Mehta [https://community.jboss.org/people/niteshmehta] created the discussion
"clustering problem with JBoss Messaging in JBoss 5.1"
To view the discussion, visit: https://community.jboss.org/message/776085#776085
--------------------------------------------------------------
We have a cluster environment with two nodes (Node1 and Node2) of JBoss 5.1. We have two queues deployed.
When we bring up the Node1 and view consumer count of queue in admin-console it shows consumer count as 1 for each queue. Till now everything fine and work as expected.
When we bring up the Node2 of cluster and view consumer count of queues in admin-console of both the node, we observe a random behavior sometime consumer count is incremented to 2 on Node1 whereas consumer count stays 0 on Node 2 and some time it is increase to 1 on Node2.
When we have consumers for queues on both the node i.e.
Node1 Queue1 consumer count =1
Node1 Queue2 consumer count =1
Node2 Queue1 consumer count=1
Node2 Queue2 consumer count=1
Everything work as expected
BUT
When we have a situation like
Node1 Queue1 consumer count =2
Node1 Queue2 consumer count =1
Node2 Queue1 consumer count=0
Node2 Queue2 consumer count=1
Then all the messages which reach Node2 Queue1 are not processed.
When one of the nodes goes down these failover happens and these messages get processed
This situation is happening very often.
We tried to upgrade to JBoss Messaging 1.4.5 and JBossRemoting 2.5.2.SP3 but it didn’t help.
messaging-service.xml
<?xml version="1.0" encoding="UTF-8"?>
<!--
The JBoss Messaging service deployment descriptor.
$Id: messaging-service.xml 85945 2009-03-16 19:45:12Z dimitris(a)jboss.org (mailto:dimitris@jboss.org) $
-->
<server>
<!-- ServerPeer MBean configuration
============================== -->
<mbean code="org.jboss.jms.server.ServerPeer"
name="jboss.messaging:service=ServerPeer"
xmbean-dd="xmdesc/ServerPeer-xmbean.xml">
<!-- The unique id of the server peer - in a cluster each node MUST have a unique value - must be an integer -->
<attribute name="ServerPeerID">${jboss.messaging.ServerPeerID:0}</attribute>
<!-- The default JNDI context to use for queues when they are deployed without specifying one -->
<attribute name="DefaultQueueJNDIContext">/queue</attribute>
<!-- The default JNDI context to use for topics when they are deployed without specifying one -->
<attribute name="DefaultTopicJNDIContext">/topic</attribute>
<attribute name="PostOffice">jboss.messaging:service=PostOffice</attribute>
<!-- The default Dead Letter Queue (DLQ) to use for destinations.
This can be overridden on a per destinatin basis -->
<attribute name="DefaultDLQ">jboss.messaging.destination:service=Queue,name=DLQ</attribute>
<!-- The default maximum number of times to attempt delivery of a message before sending to the DLQ (if configured).
This can be overridden on a per destinatin basis -->
<attribute name="DefaultMaxDeliveryAttempts">10</attribute>
<!-- The default Expiry Queue to use for destinations. This can be overridden on a per destinatin basis -->
<attribute name="DefaultExpiryQueue">jboss.messaging.destination:service=Queue,name=ExpiryQueue</attribute>
<!-- The default redelivery delay to impose. This can be overridden on a per destination basis -->
<attribute name="DefaultRedeliveryDelay">10000</attribute>
<!-- The periodicity of the message counter manager enquiring on queues for statistics -->
<attribute name="MessageCounterSamplePeriod">5000</attribute>
<!-- The maximum amount of time for a client to wait for failover to start on the server side after
it has detected failure -->
<attribute name="FailoverStartTimeout">60000</attribute>
<!-- The maximum amount of time for a client to wait for failover to complete on the server side after
it has detected failure -->
<attribute name="FailoverCompleteTimeout">300000</attribute>
<attribute name="StrictTck">false</attribute>
<!-- The maximum number of days results to maintain in the message counter history -->
<attribute name="DefaultMessageCounterHistoryDayLimit">-1</attribute>
<!-- The name of the connection factory to use for creating connections between nodes to pull messages -->
<attribute name="ClusterPullConnectionFactoryName">jboss.messaging.connectionfactory:service=ClusterPullConnectionFactory</attribute>
<!-- When redistributing messages in the cluster. Do we need to preserve the order of messages received
by a particular consumer from a particular producer? -->
<attribute name="DefaultPreserveOrdering">false</attribute>
<!-- Max. time to hold previously delivered messages back waiting for clients to reconnect after failover -->
<attribute name="RecoverDeliveriesTimeout">300000</attribute>
<!-- Set to true to enable message counters that can be viewed via JMX -->
<attribute name="EnableMessageCounters">false</attribute>
<attribute name="SuckerPassword">${queues.database.password}</attribute>
<!-- The name of the server aspects configuration resource
<attribute name="ServerAopConfig">aop/jboss-aop-messaging-server.xml</attribute>
-->
<!-- The name of the client aspects configuration resource
<attribute name="ClientAopConfig">aop/jboss-aop-messaging-client.xml</attribute>
-->
<depends optional-attribute-name="PersistenceManager">jboss.messaging:service=PersistenceManager</depends>
<depends optional-attribute-name="JMSUserManager">jboss.messaging:service=JMSUserManager</depends>
<depends>jboss.messaging:service=Connector,transport=bisocket</depends>
<depends optional-attribute-name="SecurityStore"
proxy-type="org.jboss.jms.server.SecurityStore">jboss.messaging:service=SecurityStore</depends>
</mbean>
</server>
--------------------------------------------------------------
Reply to this message by going to Community
[https://community.jboss.org/message/776085#776085]
Start a new discussion in JBoss Messaging Development at Community
[https://community.jboss.org/choose-container!input.jspa?contentType=1&con...]
11 years, 5 months
[JBoss AS 7 Development] - How create a new deployer?
by ulrichromahn
ulrichromahn [https://community.jboss.org/people/ulrichromahn] created the discussion
"How create a new deployer?"
To view the discussion, visit: https://community.jboss.org/message/777269#777269
--------------------------------------------------------------
Hi All,
I would like to create a new deployer for the following use case:
I would like to create a file, preferably an XML file, which contains a "bundle name" (not to confuse with OSGi bundles, though), and a list of JAR's, WAR's, or EAR's that should be deployed.
All those artifacts to be deployed should be specified by a URI, e.g. "file:/home/myname/deployments/my-new-app-1.0.0.jar" or "mvn:org.mydomain.app/myapp/1.0.0/war".
The file should then be picked up by my new deployer and then the list of all those artifacts should be resolved (found) according to the URI.
>From the example above, the first URI should find the "my-new-app-1.0.0.jar" on the local filesystem under "/home/myname/deployments" and then deploy it to JBoss AS 7. The second example the demonstrtes the power of this new deployer: it would try to find a WAR with the filename "myapp-1.0.0.war from a Maven repository using the groupId of "org.mydomain.app" and artifactId of "myapp". My specific implementation would be configurable to look into a local ".m2" repository first and if not found, try to download it from a remote Maven repository. The URL to this repository should be configurable. This could be implemented similar to the OSGi Repository implemented as part of JBOSGI.
Here is my question:
Are there any HOWTO's, examples, or other documentation that describes how to implement a new deployer in JBoss AS7? It would even be helpful if someone could point me to some existing implementations?
I looked at the current source and tried to figure out how the deployer for the "*-ds.xml" files was implemented, but it is hard for me to see how this would be hooked into the overall JBoss deployment subsystem?
Any help or pointers would be much appreciated.
--------------------------------------------------------------
Reply to this message by going to Community
[https://community.jboss.org/message/777269#777269]
Start a new discussion in JBoss AS 7 Development at Community
[https://community.jboss.org/choose-container!input.jspa?contentType=1&con...]
11 years, 5 months
[JBoss AS 7 Development] - Connection Re-Authentication and Security Propagation [DRAFT]
by Darran Lofthouse
Darran Lofthouse [https://community.jboss.org/people/dlofthouse] modified the document:
"Connection Re-Authentication and Security Propagation [DRAFT]"
To view the document, visit: https://community.jboss.org/docs/DOC-47864
--------------------------------------------------------------
h2. Introduction
The purpose of this article is to outline the problems that we are attempting to solve and the solution currently being considered, this work is being tracked under the following Jira issue: -
https://issues.jboss.org/browse/AS7-5901 https://issues.jboss.org/browse/AS7-5901
Currently for remote EJB invocations (Actually all invocations to the server but in this case EJB invocations are the priority) a Remoting connection is established by the client, early in establishing this connection the remote client performs authentication using SASL - once authenticated the authentication is valid for the life of the connection. As EJB invocations are received the identity on this connection is the identity used for the EJB call.
The following diagram illustrates the exising calls for remote EJB clients: -
https://community.jboss.org/servlet/JiveServlet/showImage/19891/Existing+... https://community.jboss.org/servlet/JiveServlet/downloadImage/19891/Exist...
The established connection here is a Remoting connection, the connection itself is independent of any service being accessed and on establishing the connection authentication is performed using the associated realm. Subsequently when the client connects to the EJB Container and sends a request to a deployed EJB the identity used for the EJB call is the identity taken from the underlying connection. As the authentication takes place as the connection is established the only way for the clients to send in requests as an alternative user is to establish a new connection as the new user.
A second scenario is where the call is also passed from one server to another: -
https://community.jboss.org/servlet/JiveServlet/showImage/19892/Existing+... https://community.jboss.org/servlet/JiveServlet/downloadImage/19892/Exist...
In this second scenario there is now a connection from the first server to the second server, this connection also requires authentication and the call to the EJB on the second server runs as the identity of this second connection.
These two diagrams illustrate the problems to be solved: -
* For a client to run as different identities different connections are required for each identity.
* For a server to server call the identity on the second server is the identity of the connection and not the original caller.
h3. Remoting Authentication
Before reviewing alternative solutions it is worth describing the decisions relating to the authentication of the actual connection as at the very minimum it is desirable that we do not undermine this with a solution that allows interception of the exchanges in such a way that either passwords are revealed or items are revealed that could be basis for a plain text attack.
When a client attempts to connect to the Remoting connection a challenge is sent back to the client containing a list of supported authentication SASL mechanisms that the client can select from to attempt to authenticate, the client selects on and attempts the authentication. If authentication succeeds then the client can then request to connect to the service it wished to use, if not the client is re-challenged with the list of mechanisms and this is repeated until the client either successfully authenticates or the list is exhausted.
The SASL mechanisms that are offered are selected based on the capabilities of the backing user store - as an example if we have a user store what we can query to obtain the users password or a pre-prepared hash of their password we offer the client the Digest-MD5 mechanism - however if we can only verify a supplied password but not generate the hashes required for Digest based authenitcation then PLAIN is offered as a mechanism.
A second SASL mechanism that we also support is the External mechanism, this mechanism is a special mechanism in that it automatically authenticates as an identity associated with the surrounding connection - currently we use this for ClientCert style authentication where after a TLS connection is established authentication will then proceed based on the clients certificate.
Another mechanism that we are currently adding support for is GSSAPI, this is a mechanism that authenticates a user by the use of authentication tokens with no exchange of passwords between the points involved in the authentication process.
The ability to authenticate using these different approaches where we can reduce the places where either passwords or replayable tokens are visible is the key reason why we do not want to introduce those kind of vulnerabilities in the solution to the two problems being described here.
Authentication is only presently performed on establishing the connection and is considered valid for the life of the connection.
h4. SASL
As described above we are using SASL for the negotiated authentication process between the client and the server, there are a couple of areas of SASL that either we don't use or we only use in a limited way that we can potentially take advantage of for some of this work.
h5. Authorization Id
For all mechanisms supported by SASL there is both an authentication id and an authorization id in the request.
* *authentication id* - This is the ID of the user actually performing the authentication i.e. this is the identity of the user we are comparing the password against.
* *authorization id* - This is the identity that we want requests to run as, i.e. this is the identity that we load the roles for.
Presently we mandate that both of these identities are the same so whilst users authenticate as themselves they can only request that the requests are run as themselves as well.
>From an AS perspective this capability of SASL starts to show some possible use when we are talking about propagating security contexts and trusting requests from other clients (in our case other servers). For any server to server connection this is most likely going to be authenticated using an identity of the server. We can now review the option of allowing the server accounts to be able to request that a request is run using a different authorization id.
This now means that for a server account say 'ServerA' we are saying that we know that 'ServerA' has the capability to authenticate the remote users so we can now configure a sub-set of the users that 'ServerA' can now ask that requests are executed on behalf of.
h5. External
The external SASL mechanism is a special SASL mechanism that uses something from the connection for the authentication step, presently use this mechanism to authenticate based on the clients certificate after a TLS connection had already been established - we can do this as the TLS negotiation process also went through a verification process using the trust store to verify that the clients certificate is trusted.
When looking at the existing connections one area of solutions that will be explored below is to consider repeating the SASL process within an already authenticated connection. The External mechanism could then have another role to play in that now there is already an authenticated user associated with the connection (for these issues most likey authenticated as a server) - combined with the authorization ID as discussed above a server could authenticate using this mechanism and specify the authorization id without having to repeat the full authentication process that was performed as the connection was established.
h5. GSSAPI
This one is not a mechanism we are currently using but are close to being able to enable this feature - in short this is enabling Kerberos based authentication which also includes identity propagation capabilities without needing to drop to using the authorization id. For anyone really serious about security context propagation I would most likely recommend this approach - however this is very dependent on the related infrastructure so may not be a suitable as a one size fits all solution.
h5. Callback Handlers
Where SASL is used clients are expected to provide a CallbackHandler that will be called by a mechanism to request information that is required to make the call, the idea being that these CallbackHandlers contain no data and pro-actively prompt for these values ony if they are actually required. Although at some point we would like to review the CallbackHandler API due to some deficiencies in the current API that is not a priority here.
h4. Multi Realm Support
Presently within JBoss AS7 a single realm is used for the authentication process as the connection is established, there is a desire to support multiple realms however multiple realms on connecting to the server is currently outside the scope of this feature being considered.
However if we implement a solution that uses any form of authentication then that solution should allow for the authentication to be against different realms. The feasibility and details for this should be considered in more depth with the selected solution.
h2. Proposed Solutions
This section describes the solutions currently considered and where appropriate describes why those solutions are currently discounted, at this point this is intended to be for discussion rather than a final definitive decision.
h3. Solution from Previous Releases
In previous AS releases unless a custom RMI socket was used the connections to the application server were not authenticated, instead the username and credential would be passed along with the EJB invocation and intercepted before the call reached the EJB - the supplied information would then be used to authenticate the remote user before allowing the call to proceed.
https://community.jboss.org/servlet/JiveServlet/showImage/19893/Previous+... https://community.jboss.org/servlet/JiveServlet/downloadImage/19893/Previ...
Where a client wanted to run as multiple identities that was fine as for each invocation a different username and password could be set for the call.
This approach also potentially allowed for the security context to be passed onto subsequent servers as the contents from this message invocation are available.
https://community.jboss.org/servlet/JiveServlet/showImage/19894/Previous+... https://community.jboss.org/servlet/JiveServlet/downloadImage/19894/Previ...
Whilst this approach does solve the problem of being able to switch identities and propagate identities it suffers from the problem that the users password is sent in the clear so should we undertake a similar solution for AS7 it would undermine the protection available from the currently available SASL mechanisms, in addition to this it is assuming that a username / password based authentication is always the approach we will want to take even though there are now alternative mechanisms in common use.
h3. Reauthenticate The Connection
As the calls are executed as the identity of the connection one approach could be to allow the client side to initiate a re-authentication of the connection so that a different identity can be used.
https://community.jboss.org/servlet/JiveServlet/showImage/19895/Reauthent... https://community.jboss.org/servlet/JiveServlet/downloadImage/19895/Reaut...
Whilst this would allow a client to switch identities and it could potentially be implemented using the SASL mechanisms the biggest issue here is if the client is multi-threaded and wants to run as multiple identities concurrently. At best the client would need to maintain a pool of connections one for each identity in use and if all identities could be used at once then it is no better than the current situation.
The multi threaded client issue is also made worse in the server to server case where sharing a single connection would be a major benefit in reducing the resources used.
Above where the existing Remoting authentication is described the capabilties relating to the authorization id and the External mechanism are described, for a server to server connection we could use both of these to re-authenticate the connection to switch the authorization id to the id we wish to run as - however in a server to server environment this one identity at a time per connection issue becomes even greater.
h3. Authentication On Invocation
Moving beyond re-authenticating the whole connection another posibility is to add authentication to the actual invocation, above the previous approach of bundling credentials with an invocation was illustrated but another option now would be to add SASL authentication to the invocation process.
For the connection re-authentication of a single client the requests would be intercepted like this: -
https://community.jboss.org/servlet/JiveServlet/showImage/19897/SASL+Per+... https://community.jboss.org/servlet/JiveServlet/downloadImage/19897/SASL+...
The authentication could be optional with one of the following being used to enable it for a request: -
* A flag from the client indicating that they want the authentication to occur.
* A failed authorization check indicating the current client does not have the required permissions so now give them an opportunity to switch to an identity that does.
Alternatively it could be mandatory for the request and where no switch is required the client could use the External mechanism to ask that the current invocation is executed as the previously authenticated identity.
For the client to server scenario it would be most likely that the client is using the SASL mechanisms that perform a full authentication i.e. one of the username password mechanisms with the client knowing the usernames and password of each of the identities it wishes to use. However if the authorization ID capability is supported there is nothing to stop clients from using it should their user be allowed to do so.
A server to server call would not look like: -
https://community.jboss.org/servlet/JiveServlet/showImage/19898/SASL+Per+... https://community.jboss.org/servlet/JiveServlet/downloadImage/19898/SASL+...
The client to server portion of the call is described above but the server to server portion of the call would either be dependent on the authorization id and possibly the External mechanism capabilties or the set up would be using GSSAPI end to end to make use of the propagation capabilities of GSSAPI. Either way existing connections are now re-used without introducing a serialization of requests over the connections as multiple requests could be executed as different users concurrently.
One point to keep in mind is that although the diagram only shows one client calling the first server there could in fact be many clients calling that server each with their own connection to the server and then a single connection between the servers.
There are a couple of down sides for this approach.
* The additional SASL challenge is deep within the protocol of the service being called, if we wanted to repeat this for further protocols e.g. JNDI, management, JMX etc... then it will need to be implemented again for each of these.
* Where on the client side a CallbackHandler may be used to supply credentials to the client side of a selected SASL mechanism - if the authentication is using a one time password the client will be prompted to supply this on each invocation.
h3. Authentication Service
This solution is to add a new additional service to the server, clients can choose to call this service perform a SASL authentication, recieve a token after authentication is complete and pass this token in subsequent request to ask that the invocation containing the token is executed as the authorization id from the SASL authentication previously completed.
https://community.jboss.org/servlet/JiveServlet/showImage/19899/Auth+Serv... https://community.jboss.org/servlet/JiveServlet/downloadImage/19899/Auth+...
Within this solution the majority of the new interactions are handled using this new 'Authentication Service' this service is responsible for handling a new SASL authentication process and returning an authentication token to the client. It is anticipated that a process like this would support all SASL authentication mechanisms currently supported including different authorization IDs and the alternative use of the External mechanism also described above.
As in the previous solution it is anticipated that the client would be using mechanism based on having the required information to perform the authentication as different users however it is possible that the client could have the ability to request a different authorization id.
A small change is still required for the EJB invocation in that the token needs to be passed with the request, intercepted and the real identity that token maps to retrieved from the Authentication Service.
The server to server case then looks like this: -
https://community.jboss.org/servlet/JiveServlet/showImage/19900/Auth+Serv... https://community.jboss.org/servlet/JiveServlet/downloadImage/19900/Auth+...
For the server to server call as with the previous solution the server could either make use of the External mechanism with a different authorization ID when calling the authentication service or the server could use GSSAPI if it has a forwardable GSSAPI identity - either way the server recieves back a token which it then uses on the EJB invocation.
Should other services on the server require the ability for security context propagation then the same service would be used and the only part that would need to be repeated is the passing of this security token.
h5. Token Management
By introducing a token we do not want to be introducing anything that now can be used in any form of attack based on intercepting these packets, here we have a couple of options: -
* Tie the token to the connection, replays over a different connection will be rejected - clients that re-connect will have to re-establish the connections.* This does have an implication if a CallbackHandler is in use on the client, this may be required to cache the username and password whilst being aware of any one time password requriements.
* Investigate some form of key exchange for insecure connections so the client and server can generate their own secrets, exchange them and then allow the client to prove that it can legitimatly use the token it supplied.
--------------------------------------------------------------
Comment by going to Community
[https://community.jboss.org/docs/DOC-47864]
Create a new document in JBoss AS 7 Development at Community
[https://community.jboss.org/choose-container!input.jspa?contentType=102&c...]
11 years, 5 months
.png){kind=link}
.png){kind=link}
