January 2010 - jboss-dev-forums - Jboss List Archives

[Security Development] New message: "Re: Client/Server Key Aliases at JBoss Security Domain Level"

by Stefan Guilhen

JBoss development, A new message was posted in the thread "Client/Server Key Aliases at JBoss Security Domain Level": http://community.jboss.org/message/518592#518592 Author : Stefan Guilhen Profile : http://community.jboss.org/people/sguilhen@redhat.com Message: -------------------------------------------------------------- Ovidiu, your reasoning looks good to me. I think it is worth creating our "alias-aware" KeyManager as JSSE supports this (although it doesn't provide a KeyManager with these capabilities). Let's go ahead and include this. -------------------------------------------------------------- To reply to this message visit the message page: http://community.jboss.org/message/518592#518592

14 years, 4 months

1
0
0 / 0

[Security Development] New message: "Re: Support for External Credentials in LdapExtLoginModule"

by Stefan Guilhen

JBoss development, A new message was posted in the thread "Support for External Credentials in LdapExtLoginModule": http://community.jboss.org/message/518579#518579 Author : Stefan Guilhen Profile : http://community.jboss.org/people/sguilhen@redhat.com Message: -------------------------------------------------------------- This sounds interesting. Is this feature requested only for LdapExtLoginModule or can it be also used in other modules, such as the regular LdapLoginModule? -------------------------------------------------------------- To reply to this message visit the message page: http://community.jboss.org/message/518579#518579

14 years, 4 months

1
0
0 / 0

[Security Development] New message: "Re: Configurable keyStoreProvider, trustStoreProvider, etc. at JaasSecurityDomain level"

by Stefan Guilhen

JBoss development, A new message was posted in the thread "Configurable keyStoreProvider, trustStoreProvider, etc. at JaasSecurityDomain level": http://community.jboss.org/message/518540#518540 Author : Stefan Guilhen Profile : http://community.jboss.org/people/sguilhen@redhat.com Message: -------------------------------------------------------------- I think we already have a couple of these things in *JaasSecurityDomain*, like the factory algorithms, factory providers, etc. If we have missed any property we should definitely include it. As you have tested the changes, I think you can create the Jira and commit your additions directly. -------------------------------------------------------------- To reply to this message visit the message page: http://community.jboss.org/message/518540#518540

14 years, 4 months

1
0
0 / 0

[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

14 years, 4 months

1
0
0 / 0

[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/518506#518506 Author : Ales Justin Profile : http://community.jboss.org/people/alesj Message: -------------------------------------------------------------- > > Now, what if (although probably unlikely) someone defines -Dorg.jboss.kernel.plugins.annotations.BeanAnnotationAdapter=some.class.without.these.Methods? His/her problem. ;-) btw: you don't need to define class attribute in 2nd bean (at least I think so) -------------------------------------------------------------- To reply to this message visit the message page: http://community.jboss.org/message/518506#518506

14 years, 4 months

1
0
0 / 0

[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

14 years, 4 months

1
0
0 / 0

[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

14 years, 4 months

1
0
0 / 0

[JBoss Microcontainer Development POJO Server] New message: "Re: StructureModificationChecker and Synch with VFS3"

by Scott Stark

JBoss development, A new message was posted in the thread "StructureModificationChecker and Synch with VFS3": http://community.jboss.org/message/518415#518415 Author : Scott Stark Profile : http://community.jboss.org/people/scott.stark@jboss.org Message: -------------------------------------------------------------- I need to review the current profileservice integration with modification checking as its embedded in the profile repository. The idea there was that the repository implementation could mediate how deployments were added/modified. Whether deployments were in a VFS was a repository implementation detail. -------------------------------------------------------------- To reply to this message visit the message page: http://community.jboss.org/message/518415#518415

14 years, 4 months

1
0
0 / 0

[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

14 years, 4 months

1
0
0 / 0

[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

14 years, 4 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums January 2010