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

[Design of Security on JBoss] - Stateful Session Beans and RunAsIdentity mismatch

by anil.saldhana＠jboss.com

Assume we have a regular bean A which makes a call on a Stateful Session B. Bean A configures a RunAsIdentity of (principal=anil,roles=user). Now when A makes a call on B, the following things happen: 1) The current subject in A is pushed on the subject context. 2) The StatefulSessionInstanceInterceptor pushes a null subject on to the subject context as per: | /* The security context must be established before the cache | lookup because the activation of a session should have the caller's | security context as ejbActivate is allowed to call other secured | resources. Since the pm makes the ejbActivate call, we need to | set the caller's security context. The only reason this shows up for | stateful session is that we moved the SecurityInterceptor to after | the instance interceptor to allow security exceptions to result in | invalidation of the session. This may be too literal an interpretation | of the ejb spec requirement that runtime exceptions should invalidate the session. | */ | SecurityActions.pushSubjectContext(mi.getPrincipal(), mi.getCredential(), null); | 3) The SecurityInterceptor fronting B finds that there is a RunAsIdentity configured. Hence does not do a authentication check, but duplicates the subject context on the SA stack. Now because of step 2 (a null subject gets duplicated). This use case is only for Stateful session beans. I think in step 2, there is a need to check for availability of RunAsIdentity, failing which a null subject can be pushed in. Thoughts? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3980146#3980146 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3980146

19 years, 5 months

1
0
0 / 0

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

by ovidiu.feodorov＠jboss.com

Tim wrote : | However I still believe we need very low level access for high performance operations. | For example, in the proposal, "raw" data is sent/received in byte[]s, but in the case that the implementation was using NIO this would mean copying to and from byte buffers which is going to be slow. | 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. However, there's a little bit deeper problem here. I've just talked with Tom, his observation was that while he agrees with the necessity of making the distinction between synchronous and asynchronous calls at the API level, he doesn't necessarily want to expose access to the "low level" layers from the high level API. His argument is that top-level Remoting API should be kept as simple as possible, and some transports may simply not be able to honor the low level access exposed by the extAPI. Instead of exposing send(byte[]) (or send(ByteBuffer)) kind of methods, he is suggesting a chained marshaller mechanism instead, where we can plug-in our own low-level processing. It is not very clear to me how this would work and I need more details. He said that he's currently experimenting with it, and he needs a couple of days to reach a conclusion. He suggested a conference in two days from now, where we discuss his findings, and agree on the final version of http://wiki.jboss.org/wiki/Wiki.jsp?page=JBossMessagingRemotingAPIExtensions. I think it's a good idea, we should decide on the final version of the document ASAP. Tom will let us know when he's done with his experimentation (hopefully not later than mid week). I will send everybody interested the conference details. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3980142#3980142 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3980142

19 years, 5 months

1
0
0 / 0

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

by clebert.suconic＠jboss.com

+1 : I don't like the idea of dealing with byte[] buffers directly. You need aways replicate stuff when you could parse it from the buffer directly. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3980138#3980138 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3980138

19 years, 5 months

1
0
0 / 0

[Design of JBossXB] - Unmarshaller/Marshaller support for javax.xml.transform.Sour

by jason.greene＠jboss.com

We have a task on our roadmap (after TCK completion)[1] to remove string processing from jbossws. In order to do this, we would need an enhancement to JBossXB that allowed parsing of DOM fragments. The best way to do this would be to add support for JAXP Source/Result objects as parameters. Then we have the option to either optimize a particular source ourselves, or if not known, we can simply delegate to the JAXP transformer. This is also required by JAXB, so if compatibility is still on the roadmap, it would need to be done anyway. [1] http://jira.jboss.org/jira/browse/JBWS-1314 -Jason View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3980136#3980136 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3980136

19 years, 5 months

1
0
0 / 0

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

by clebert.suconic＠jboss.com

"timfox" wrote : Clebert- | | There should be no need to transfer anything from one channel to another. | | You just need to load the old channel on the new node, keeping the same channel id. It looks like we will have to think a little bit more about failover on durable subscriptions. As far as I looked into the code, Postoffice will only accept one binding using a single name. 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) but now I realize there might be a problem: What if another client is already subscribed to an existent queue. Can we have two clients with the same connectionID/subscriptionName? Of course there are implications i was going to ask, like View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3980134#3980134 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3980134

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

We need 2 things: 1. Ability to generate a v3 cert, bouncy castle does support this. Right now I tell people to use openssl. 2. Support for subject key identifier code follows 3. 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; | } | Let me know how you would like this represented as JIRA issues. -Jason View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3980129#3980129 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3980129

19 years, 5 months

1
0
0 / 0

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

by bstansberry＠jboss.com

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. 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) | 3) Eviction configuration naming. The Pojo configuration looks like this: class EvictionConfig -- top level object. Configure your default eviction policy here, plus the interval for the eviction thread. Also takes a list of... class EvictionRegionConfig -- one per region. Configure the Fqn here, plus the class name of the EvictionPolicy (if you want to override the overall default). Also takes an impl of.... interface EvictionConfiguration. the type-specific config for the EvictionPolicy. Couple problems here. First "EvictionConfiguration" would be better named "EvictionPolicyConfig", since its a config for a specific policy. But, that interface already exists in 1.4, so changing that name will break any existing custom impls. Don't know if we care about that. Second, there's already an unused interface named EvictionPolicyConfig, along with a DefaultEvictionPolicyConfig impl. That code is unused; looks like it was meant more as a top-level config object. We should drop that code after ensuring that any design ideas from it get picked up in the new stuff. Any thoughts/suggestions are most welcome. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3980128#3980128 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3980128

19 years, 5 months

1
0
0 / 0

[Design of JBoss Labs] - Re: 'CMS Template' folder is out of date

by adamw

Hello, I've update the CMS template. Hope this helps. -- Adam View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3980121#3980121 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3980121

19 years, 5 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: JBMICROCONT-23, support for lifecycle annotations

by alesj

How to add lifecycle method's parameters support through annotations? I can probably write something for @Inject annotation on the method's parameter. Should my annotation lookup go over BeanInfo -> MethodInfo, or MetaDataContext. Or it doesn't matter - since this should be the same after DescribeAction? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3980118#3980118 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3980118

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

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. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3980115#3980115 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3980115

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