October 2006 - jboss-dev-forums - Jboss List Archives

[Design of JBoss Web Services] - Re: What do we need in terms of x509 cert processing for ws

by scott.stark＠jboss.org

Ok, so we need a basic ca tool set. Its been a while since I looked at ejbca (http://sourceforge.net/projects/ejbca/) so its worth looking at how retargetable it would be for this effort. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3980175#3980175 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3980175

19 years, 5 months

1
0
0 / 0

[Design of JBoss Web Services] - Re: What do we need in terms of x509 cert processing for ws

by jason.greene＠jboss.com

In addition bc also has utility classes that decode just about every X509 attribtue that exists. For example: http://www.bouncycastle.org/docs/docs1.5/org/bouncycastle/asn1/x509/Subje... http://www.bouncycastle.org/docs/docs1.5/org/bouncycastle/asn1/x509/Attri... -Jason View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3980167#3980167 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3980167

19 years, 5 months

1
0
0 / 0

[Design of JBoss Web Services] - Re: What do we need in terms of x509 cert processing for ws

by anil.saldhana＠jboss.com

"scott.stark(a)jboss.org" wrote : "anil.saldhana(a)jboss.com" wrote : I do not think all the constituents of a X509 certificate map to standard JDK classes. An example are the Attribute Certificates that can be issued by the CA as part of a x509 certificate. | Where is this used? I'm not keen on pushing too much to pki management layer. Issuing certs for roles seems like an unnecessary indirection. | No user requests have come in this area. Mainly used in smart cards(not sure of other uses). Like you said, unnecessary indirection. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3980163#3980163 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3980163

19 years, 5 months

1
0
0 / 0

[Design of JBoss Web Services] - Re: What do we need in terms of x509 cert processing for ws

by jason.greene＠jboss.com

"scott.stark(a)jboss.org" wrote : "jason.greene(a)jboss.com" wrote : | | 1. Ability to generate a v3 cert, bouncy castle does support this. Right now I tell people to use openssl. | | | We should just look at whether bouncy castle/ejbca can be leveraged to get a sufficient cert generation capability into our codebase. | Agreed, I know we have some advanced long term goals, but I think just getting a basic tool in to begin with is important. Even if self-signing is all thats supported thats something. "scott.stark(a)jboss.org" wrote : | \Access to any raw attribute seems to exist. What is not generally available is a mechanism to control how to decode a given attribute. I would assume this is going to require ASN/DER classes (should exist in bc or even opends), along with a OID to format handler registry. The latter is core to ldap and so maybe we can leverage the opends schema handling pieces as a way to externalize the cert attribute handling as well. | Yes bc does have ASN/DER decoding: http://www.bouncycastle.org/docs/docs1.5/org/bouncycastle/asn1/package-su... If work starts in either of these areas I can try and get some time to work on this if needed. -Jason View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3980162#3980162 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3980162

19 years, 5 months

1
0
0 / 0

[Design of JBoss Web Services] - Re: What do we need in terms of x509 cert processing for ws

by scott.stark＠jboss.org

"anil.saldhana(a)jboss.com" wrote : I do not think all the constituents of a X509 certificate map to standard JDK classes. An example are the Attribute Certificates that can be issued by the CA as part of a x509 certificate. Where is this used? I'm not keen on pushing too much to pki management layer. Issuing certs for roles seems like an unnecessary indirection. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3980159#3980159 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3980159

19 years, 5 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Client failover redeliveries discussion

by timfox

"clebert.suconic(a)jboss.com" wrote : | | As far as I looked into the code, Postoffice will only accept one binding using a single name. | | Correct. Also this applies to jms partial queues, not just durable subscriptions. anonymous wrote : | We will be loading a Durable subscription from a dead node, where the current node could have the same subscription already existent (that's why I decided to transfer contents) | postoffice needs to be extended to be able to support more than one local queue with the same name anonymous wrote : | What if another client is already subscribed to an existent queue. Can we have two clients with the same connectionID/subscriptionName? We need to cope with this too. See, I told you server side failover wasn't trivial :) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3980158#3980158 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3980158

19 years, 5 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Messaging and Remoting

by timfox

"ovidiu.feodorov(a)jboss.com" wrote : | Not necessarily, the Remoting implementation can create ByteBuffers by wrapping the byte[] we send as an argument without copying anything, but I don't see any problem with using ByteBuffer instead of byte[] in the method signature. I don't think wrapping the buffer around a byte[] works with direct byte buffers. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3980155#3980155 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3980155

19 years, 5 months

1
0
0 / 0

[Design of JBoss Web Services] - Re: What do we need in terms of x509 cert processing for ws

by scott.stark＠jboss.org

"jason.greene(a)jboss.com" wrote : | 1. Ability to generate a v3 cert, bouncy castle does support this. Right now I tell people to use openssl. | We should just look at whether bouncy castle/ejbca can be leveraged to get a sufficient cert generation capability into our codebase. "jason.greene(a)jboss.com" wrote : | 2. Support for subject key identifier code follows (Although, ideally all v3 attributes would be supported) | | | | public static byte[] getSubjectKeyIdentifier(X509Certificate cert) | | { | | // Maybee we should make one ourselves if it isn't there? | | byte[] encoded = cert.getExtensionValue("2.5.29.14"); | | if (encoded == null) | | return null; | | | | // We need to skip 4 bytes [(OCTET STRING) (LENGTH)[(OCTET STRING) (LENGTH) (Actual data)]] | | int trunc = encoded.length - 4; | | | | byte[] identifier = new byte[trunc]; | | System.arraycopy(encoded, 4, identifier, 0, trunc); | | | | return identifier; | | } | | | Access to any raw attribute seems to exist. What is not generally available is a mechanism to control how to decode a given attribute. I would assume this is going to require ASN/DER classes (should exist in bc or even opends), along with a OID to format handler registry. The latter is core to ldap and so maybe we can leverage the opends schema handling pieces as a way to externalize the cert attribute handling as well. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3980154#3980154 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3980154

19 years, 5 months

1
0
0 / 0

[Design of Security on JBoss] - Re: SecurityContext

by anil.saldhana＠jboss.com

An issue that I have noticed with Security Context with reference to RoleMapping is: If we have multiple deployments (A.war,b-ejb.jar,C.war etc) all driven by the same security domain and since the SecurityContext works at the domain level, we can have an issue if the user configures a custom role mapping module for a particular deployment (say, A.war). So the user may want a subset of roles applicable to deployment A whereas for the other deployments, a superset (or a different set of roles can apply). Unless we do a fresh creation of security context roles for each lookup of roles, there can be issues(cached roles in the context) Workaround: a) Provide a system property that is jbosssx specific that configures whether the Authorization Manager does a fresh set of security context roles (read the subject roles if any and apply mapping) on each look up OR b) Provide options on the Authorization Manager Service to be provided to each of the Authorization Managers possible. I like b) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3980152#3980152 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3980152

19 years, 5 months

1
0
0 / 0

[Design of JBossCache] - Re: POJOization of config elements

by scott.stark＠jboss.org

"bstansberry(a)jboss.com" wrote : As mentioned on the dev list, a lot has been checked in on this. There are some bits of ugliness. Manik, you pointed out the problem with the use of inner classes; I should be able to fix that today. | | Other ugliness: | | 1) MC doesn't like overloading the setter on a property, which is an issue for the properties that are enum types. E.g.: | | | | public CacheMode getCacheMode() | | public void setCacheMode(CacheMode mode) | | public void setCacheMode(String mode) | | | | doesn't work; the MC wants to pass String "REPL_ASYNC" to the overloaded method that takes CacheMode, and thus blows up. | | To fix, I had to do this for CacheMode, IsolationLevel and NodeLockingScheme: | | | | public CacheMode getCacheMode() | | public void setCacheMode(CacheMode mode) | | public void setCacheMode(String mode) // maybe redundant?? | | public String getCacheModeString() | | public void setCacheModeString(String mode) | | | | I don't know if it's practical to add a PropertyEditor to MC to handle enum conversions; for now the above is ugly but works. | It should not require a PropertyEditor as there already is the Enum.valueOf(Class enumType, String name) method. Its just a question of xml configuration parsing layer recognizing the overloaded method and using valueOf on the string accessor. I'll create a jira issue for this. "bstansberry(a)jboss.com" wrote : | 2) Names of properties in Configuration. Configuration can take 2 different types for each of the 3 complex sub-configurations (BR, cache loading, eviction). These are an Element, for legacy support, and a pojo for configuration via the MC. So, 2 properties for each sub-configuration. Problem is naming these properties; the Element properties already have names, but the naming conventions are inconsistent. Changing the Element properties will break existing config files, so I worked around that when naming the pojo properties. Ugly, completely inconsistent result is: | | | | // BR | | public Element getBuddyReplicationConfig() | | public void setBuddyReplicationConfig(Element config) | | | | public BuddyReplicationConfig getBuddyReplicationConfiguration() | | public void setBuddyReplicationConfiguration(BuddyReplicationConfig config) | | | | // Cache Loader | | public Element getCacheLoaderConfiguration() | | public void setCacheLoaderConfiguration(Element config) | | | | public CacheLoaderConfig getCacheLoaderConfig() | | public void setCacheLoaderConfig(CacheLoaderConfig config) | | | | // Eviction | | public Element getEvictionPolicyConfig() | | public void setEvictionPolicyConfig(Element config) | | | | public EvictionConfig getEvictionConfig() | | public void setEvictionConfig(EvictionConfig config) | | | | One temptation is to break compatibility with existing config files for BR by swapping the property names. There aren't likely to be many existing configs that have BR. E.g. | | | | public Element getBuddyReplicationConfiguration() | | public void setBuddyReplicationConfiguration(Element config) | | | | public BuddyReplicationConfig getBuddyReplicationConfig() | | public void setBuddyReplicationConfig(BuddyReplicationConfig config) | | | We should not be exposing any dom objects via the configuration objects. That should only be done via legacy configuration wrapper classes that turn around and write to the pure object based configuration instance. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3980149#3980149 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3980149

19 years, 5 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums October 2006