[Design of JBoss jBPM] - Re: web services question
by tom.baeyens＠jboss.com
why do you mention the xsd. if i look at your examples (which is very similar to what i want), i see a very limited schema that is fixed for all commands:
<command name="[xsd:string]" [other attibutes optional]>
| [any mixed content]
| </command>
|
then at the server side, we would need a mapping command names and ParsableCommand classes.
do you think it would be suitable if we would use DOM for this parsing/generation of XML ?
then a ParsableCommand parser interface could look like this:
public interface ParsableCommand {
| Element execute(Element element);
| }
then we need to write the infrastructure for 1 document style webservice with one method that unwraps these command from the SOAP envelopes, extract the command DOM element, lookup/instantiate the appropriate parsable command and invoke the execute method.
is that close to what you had in mind too ?
but i don't know yet which java WS technology we can use to implement this kind of infrastructure.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3968018#3968018
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3968018
18 years
[Design of JBoss internal QA (Test Suite)] - SSLUnitTestCase failures with the IBM JVM
by mwringe
Hi,
I opened a bug about the test failures for the org.jboss.test.web.test.ssl.SSLUnitTestCase failures when an IBM JVM is used(JBAS-3570), but looking into it more, I am wondering that the failures may be more of a configuration issue.
Initially, all org.jboss.test.web.test.ssl.SSLUnitTestCase test fail, giving a Connection Refused error:
anonymous wrote :
| java.net.ConnectException: Connection refused
| at java.net.PlainSocketImpl.socketConnect(Native Method)
| at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:336)
| at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:201)
| at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:188)
|
Looking at the logs, this is failing due to the server trying to use the SunX509 algorithm. The IBM JVM uses the Ibmx509 algorithm instead.
The algorithm can be changed in the server.xml of the jbossweb-tomcat55.sar, but then the server gives the following errors:
anonymous wrote :
| Testcase: testHttps took 0.017 sec
| Caused an ERROR
| protocol version
| javax.net.ssl.SSLHandshakeException: protocol version
| at com.ibm.jsse.bv.a(Unknown Source)
| at com.ibm.jsse.b.a(Unknown Source)
| at com.ibm.jsse.b.write(Unknown Source)
| at org.apache.commons.httpclient.HttpConnection$WrappedOutputStream.write(HttpConnection.java:1360)
| at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:86)
| at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:144)
| at org.apache.commons.httpclient.HttpConnection.flushRequestOutputStream(HttpConnection.java:790)
| at org.apache.commons.httpclient.HttpMethodBase.writeRequest(HttpMethodBase.java:2271)
| at org.apache.commons.httpclient.HttpMethodBase.processRequest(HttpMethodBase.java:2651)
| at org.apache.commons.httpclient.HttpMethodBase.execute(HttpMethodBase.java:1087)
| at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:643)
| at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:497)
| at org.jboss.test.web.test.ssl.SSLUnitTestCase.doHttps(SSLUnitTestCase.java:117)
| at org.jboss.test.web.test.ssl.SSLUnitTestCase.testHttps(SSLUnitTestCase.java:77)
| at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
| at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
| at junit.extensions.TestSetup.run(TestSetup.java:23)
|
Any ideas on how to get these tests to pass with the IBM JVM?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3967975#3967975
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3967975
18 years
[Design of Security on JBoss] - Re: SecurityContext
by scott.stark＠jboss.org
The SecurityContext has to have the authenticated identity(s) as it needs to be a superset of the existing SecurityAssociation context of principal, credential and Subject. I'm thinking of something more like:
| class SubjectInfo
| {
| Principal authenticationPrincipal;
| Object authenticationCredential;
| Subject subject;
| }
| class abstract SecurityContext
| {
| /** Key into the data map for the java.security.acl.Group representing the user roles
| Group roles = (Group) sc.getData().get(ROLES);
| */
| public final String ROLES = "ROLES";
| ...
|
| SubjectInfo getSubjectInfo();
| HashMap<String, Object> getData();
| public AuthorizationManager getAuthorizationManager();
| }
|
We also need an extension of the AuthenticationManager to deal with the mapping of identity and trust.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3967970#3967970
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3967970
18 years
[Design of Clustering on JBoss (Clusters/JBoss)] - Re: Using JBossSerialization with HttpSession Replication (J
by bstansberry＠jboss.com
For now, I'm not even sure I want this end-user configurable. I as a developer currently need it configurable so I can easily benchmark the effect of using JBoss Serialization. Based on those results we can then decide if we want it to be end-user configurable. But for my temporary purposes configuration via a system property is more than adequate. So, as we discussed, please do it that way. Go ahead and invent any property you want, just make sure it's prefixed with 'jboss.'
If we later decide we want it to be end-user configurable I'd lean toward #1. The difficulty with #2 is a JBossCacheManager isn't a regularly deployed MBean service where you can dependency inject. The dependency injection would be to the Tomcat service, and TomcatDeployer would then have to programmatically pass it into the JBossCacheManager. I'd prefer not to do that, as 1) it makes Tomcat service more brittle by adding a dependency that's only needed for a specialized case and 2) it further couples the deployer and the manager.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3967922#3967922
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3967922
18 years
[Design of Security on JBoss] - Re: JBoss Security Service Provider Interface Extension
by anil.saldhana＠jboss.com
Here is a snip of the configuration that drives the role mapping logic.
| <?xml version="1.0" encoding="UTF-8"?>
| <server>
| <mbean code="org.jboss.security.auth.login.DynamicLoginConfig"
| name="jboss.security.tests:service=DynamicLoginConfig">
| <attribute name="PolicyConfig" serialDataType="jbxb">
| <jbsx:policy xsi:schemaLocation="urn:jboss:security-config:5.0 resource:security-config_5_0.xsd" xmlns:jbsx="urn:jboss:security-config:5.0"
| xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
| <jbsx:application-policy name="jbossweb-role-map">
| <jbsx:authentication>
| <jbsx:login-module
| code="org.jboss.security.auth.spi.IdentityLoginModule"
| flag="required">
| <jbsx:module-option name="principal">SpecialUser</jbsx:module-option>
| <jbsx:module-option name="roles">testRole</jbsx:module-option>
| </jbsx:login-module>
| </jbsx:authentication>
| <jbsx:rolemapping>
| <jbsx:mapping-module code="org.jboss.security.mapping.providers.OptionsRoleMappingProvider">
| <jbsx:module-option name="rolesMap"
| serialDataType="jbxb">
| <java:properties xmlns:java="urn:jboss:java-properties"
| xmlns:xs="http://www.w3.org/2001/XMLSchema-instance"
| xs:schemaLocation="urn:jboss:java-properties resource:java-properties_1_0.xsd">
| <java:property>
| <java:key>testRole</java:key>
| <java:value>AuthorizedUser,InternalUser</java:value>
| </java:property>
| </java:properties>
| </jbsx:module-option>
| <jbsx:module-option name="replaceRoles">false</jbsx:module-option>
| </jbsx:mapping-module>
| </jbsx:rolemapping>
| </jbsx:application-policy>
| </jbsx:policy>
| </attribute>
| <depends optional-attribute-name="LoginConfigService">
| jboss.security:service=XMLLoginConfig
| </depends>
| <depends optional-attribute-name="SecurityManagerService">
| jboss.security:service=JaasSecurityManager
| </depends>
| </mbean>
| </server>
|
In the SecurityContext.setRoles call, a call is made out to the rolemapping framework to update the roles (if needed).
The interface for the MappingProvider is:
| package org.jboss.security.mapping;
|
| import java.util.Map;
| public interface MappingProvider
| {
| /**
| * Initialize the provider with the configured module options
| * @param options
| */
| void init(Map options);
|
| /**
| * Map the passed object
| * @param map A contextual map that can provide information to the provider
| * @return mapped result
| */
| Object performMapping(Map map);
| }
|
The generic MappingContext class is:
| package org.jboss.security.mapping;
|
| /**
| * Generic Context used by the Mapping Framework
| */
| public class MappingContext
| {
| private List modules = new ArrayList();
|
| public MappingContext(List mod)
| {
| this.modules = mod;
| }
|
| /**
| * Apply mapping semantics on the passed object
| * @param obj Generic Object
| * @return Mapped Object
| */
| public Object performMapping(Map obj)
| {
| int len = modules.size();
| Object returnObj = null;
|
| for(int i = 0 ; i < len; i++)
| {
| MappingProvider mp = (MappingProvider)modules.get(i);
| returnObj = mp.performMapping(obj);
| }
|
| return returnObj;
| }
| }
|
This forms the basis for the mapping framework. The MappingContext/MappingProvider combination will work for the use cases currently identified. The locations where the various mapping sematics (identity, certificate, rolemapping etc) need to be applied in the call path needs to be identified (but should be easy).
A similar setup exists for the Auditing framework with pluggable audit providers configured at the security domain level (TODO)
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3967909#3967909
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3967909
18 years