[Security Development] New message: "Re: Option for Client Authentication at JBoss Security Domain Level"
by Stefan Guilhen
JBoss development,
A new message was posted in the thread "Option for Client Authentication at JBoss Security Domain Level":
http://community.jboss.org/message/518531#518531
Author : Stefan Guilhen
Profile : http://community.jboss.org/people/sguilhen@redhat.com
Message:
--------------------------------------------------------------
I don't see how this is different from setting the *needsClientAuth* property directly in the DomainServerSocketFactory:
<mbean code="org.jboss.invocation.jrmp.server.JRMPInvoker"
name="jboss:service=invoker,type=jrmp,socketType=SSLSocketFactory,wantsClientAuth=true">
<attribute name="RMIObjectPort">0</attribute>
<attribute name="RMIClientSocketFactory">org.jboss.security.ssl.RMISSLClientSocketFactory
</attribute>
<attribute name="RMIServerSocketFactoryBean"
attributeClass="org.jboss.security.ssl.RMISSLServerSocketFactory"
serialDataType="javaBean">
<property name="bindAddress">${jboss.bind.address}</property>
<property name="securityDomain">java:/jaas/rmi-ssl</property>
<property name="needsClientAuth">true</property>
<property name="CiperSuites">TLS_DHE_DSS_WITH_AES_128_CBC_SHA</property>
<property name="Protocols">SSLv2Hello,SSLv3,TLSv1</property>
</attribute>
</mbean>
The needsClientAuth property is used when creating the SSLServerSocket to indicate that client authentication is required. If the client doesn't provide credentials, the SSL negotiation will fail.
There is also the wantsClientAuth property that can be used to indicate that client authentication will be requested during the negotiation phase. In this case, however, if the client doesn't provide the credentials, the SSL negotiation will continue.
Note: in the JRMPInvoker sample above we are using the RMISSLServerSocketFactory. It implements the RMIServerSocketFactory interface and delegates all methods to the DomainServerSocketFactory. So setting the needsClientAuth property there will end up setting the same property in DomainServerSocketFactory.
--------------------------------------------------------------
To reply to this message visit the message page: http://community.jboss.org/message/518531#518531
15 years
[JBoss Microcontainer Development] New message: "Re: Optimizing aop lifecycle"
by Kabir Khan
JBoss development,
A new message was posted in the thread "Optimizing aop lifecycle":
http://community.jboss.org/message/518501#518501
Author : Kabir Khan
Profile : http://community.jboss.org/people/kabir.khan@jboss.com
Message:
--------------------------------------------------------------
So you mean something along the lines of
<bean name="BeanAnnotationAdapterFactory" class="org.jboss.kernel.plugins.annotations.BeanAnnotationAdapterFactory">
<constructor factoryMethod="getInstance"/>
</bean>
<bean name="BeanAnnotationAdapter" class="org.jboss.kernel.plugins.annotations.CommonAnnotationAdapter">
<constructor factoryMethod="getBeanAnnotationAdapter">
<factory bean="BeanAnnotationAdapterFactory"/>
</constructor>
<incallback method="addAnnotationPlugin"/>
<uncallback method="removeAnnotationPlugin"/>
</bean>
Now, what if (although probably unlikely) someone defines -Dorg.jboss.kernel.plugins.annotations.BeanAnnotationAdapter=some.class.without.these.Methods?
--------------------------------------------------------------
To reply to this message visit the message page: http://community.jboss.org/message/518501#518501
15 years
[JBoss Microcontainer Development] New message: "Re: Optimizing aop lifecycle"
by Ales Justin
JBoss development,
A new message was posted in the thread "Optimizing aop lifecycle":
http://community.jboss.org/message/518420#518420
Author : Ales Justin
Profile : http://community.jboss.org/people/alesj
Message:
--------------------------------------------------------------
> Anyway, the question I really had was: am I ok to expose the add/removeAnnotationPlugin() methods in the BeanAnnotationAdapter interface
No. :-)
That is useless impl detail, that shouldn't be part of BAA.
This is what I would do
(1) expose Default/Common BAA as a bean, with callbacks on add/remove plugin (we might/should already be doing this)
(2) re-write <lifecycle-x> element to BeanMetaDataFactory handling to do config checks, and then produce LifecycleAnnotationPlugin bean
This way (1) will pick up (2), w/o any need of knowing add/remove plugin impl detail
--> less code as you don't need that last few lines; start, stop, getBAA. ;-)
--------------------------------------------------------------
To reply to this message visit the message page: http://community.jboss.org/message/518420#518420
15 years
[JBoss XML Binding Development] New message: "Re: Xml attribute list"
by Kabir Khan
JBoss development,
A new message was posted in the thread "Xml attribute list":
http://community.jboss.org/message/518414#518414
Author : Kabir Khan
Profile : http://community.jboss.org/people/kabir.khan@jboss.com
Message:
--------------------------------------------------------------
Alexey,
Can you please take a look to see if my xsd attempts are ok?
<xsd:complexType name="qualifierBeanType" mixed="true">
<xsd:annotation>
<xsd:documentation>
<![CDATA[
Qualifiers.
]]>
</xsd:documentation>
</xsd:annotation>
<xsd:choice minOccurs="0" maxOccurs="unbounded">
<xsd:any namespace="##other" processContents="strict"/>
</xsd:choice>
<xsd:attribute name="content" type="xsd:string" use="optional"/>
<xsd:attribute name="type" use="optional" default="Supplied">
<xsd:simpleType>
<xsd:restriction base="xsd:string">
<xsd:enumeration value="Supplied"></xsd:enumeration>
<xsd:enumeration value="Optional"></xsd:enumeration>
<xsd:enumeration value="Required"></xsd:enumeration>
</xsd:restriction>
</xsd:simpleType>
</xsd:attribute>
<xsd:attribute name="points" use="optional">
<xsd:simpleType>
<xsd:list>
<xsd:simpleType>
<xsd:restriction base="xsd:string">
<xsd:enumeration value="Constructor"></xsd:enumeration>
<xsd:enumeration value="Method"></xsd:enumeration>
<xsd:enumeration value="Property"></xsd:enumeration>
</xsd:restriction>
</xsd:simpleType>
</xsd:list>
</xsd:simpleType>
</xsd:attribute>
</xsd:complexType>
I think I have got the choice ok (copied from the thing I am mimicking), but am unsure about the attributes. What I want is
- An attribute called 'content' that just takes a string.
- An attribute called 'type' that can be either 'Supplied', 'Optional' or 'Required' with 'Supplied' as the default.
- An attribute called 'points' that can take one or more of 'Constructor', 'Method' or 'Property'. If I am on the right path, can I make it ignore the case of these so that 'propeRTY' etc. would be valid as well?
--------------------------------------------------------------
To reply to this message visit the message page: http://community.jboss.org/message/518414#518414
15 years
[JBoss Microcontainer Development] New message: "Re: Optimizing aop lifecycle"
by Kabir Khan
JBoss development,
A new message was posted in the thread "Optimizing aop lifecycle":
http://community.jboss.org/message/518409#518409
Author : Kabir Khan
Profile : http://community.jboss.org/people/kabir.khan@jboss.com
Message:
--------------------------------------------------------------
I have committed this and all tests pass. There are some changes in that the lifecycle-xxx now throws an error if the 'expr' attribute is used, and the 'classes' attribute must now be an annotation.
>From LifecycleBinding's start method:
*public* *void* start() *throws* Exception
{
*if* (expr != *null*)
*throw* *new* IllegalArgumentException("The 'expr' attribute has been deprecated. Only the name of an annotation in the 'classes' attribute work now.");
*if* (classes == *null*)
*throw* *new* IllegalArgumentException("Null 'classes' attribute.");
*if* (manager != *null*)
+log+.warn("The use of manager has been deprecated");
*if* (callbackBean == *null*)
*throw* *new* IllegalArgumentException("Null callback bean");
*if* (state == *null*)
*throw* *new* IllegalArgumentException("Null controller state");
*if* (name == *null*)
name = GUID.+asString+();
*if* (!classes.startsWith("@"))
*throw* *new* IllegalArgumentException("Could not parse '" + classes + " into an annotation. (It must start with '@')");
String annotationName = classes.substring(1);
Class<Annotation> clazz = *null*;
*try*
{
clazz = (Class<Annotation>)SecurityActions.+getContextClassLoader+().loadClass(annotationName);
}
*catch* (Exception e)
{
*throw* *new* IllegalArgumentException("An error occurred loading '" + classes + "'", e);
}
LifecycleAspectDependencyBuilderListItem item = *new* LifecycleAspectDependencyBuilderListItem(callbackBean, state, installMethod, uninstallMethod);
plugin = *new* LifecycleAnnotationPlugin<Annotation>(clazz, item);
getBeanAnnotationAdapter().addAnnotationPlugin(plugin);
}
--------------------------------------------------------------
To reply to this message visit the message page: http://community.jboss.org/message/518409#518409
15 years