January 2015 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-4289) Authentication bug on one-way JAX-WS methods

by Jakub Grabowski (JIRA)

[ https://issues.jboss.org/browse/WFLY-4289?page=com.atlassian.jira.plugin.... ] Jakub Grabowski commented on WFLY-4289: --------------------------------------- And the code that demonstrates issue: @Stateless @WebService @DeclareRoles("user") @Local(IMessageSender.class) @WebContext(authMethod = "BASIC") public class MessageSender implements IMessageSender { @RolesAllowed("user") @Oneway public void fails(long l) { System.out.println(">>>>>: " + l); } @RolesAllowed("user") public void works(long l) { System.out.println(">>>>>: " + l); } } > Authentication bug on one-way JAX-WS methods > -------------------------------------------- > > Key: WFLY-4289 > URL: https://issues.jboss.org/browse/WFLY-4289 > Project: WildFly > Issue Type: Bug > Components: Security, Web Services > Affects Versions: 8.2.0.Final > Reporter: Jakub Grabowski > Assignee: Darran Lofthouse > > 1. For two-way methods basic authentication and autorization works fine. User is authenticated with LDAP module and gets proper role that autorizes invocation. It works just fine. By two-way method I mean method with input and output message defined in WSDL. > 2. For one-way methods (return type void) user is not authenticated properly. It results in denial of method invocation. > 3. When I remove @RolesAllowed declaration I can see that for two-way methods authentication is correct (pricipal is set to logged user), but for one-way it's not - I get "anonymous" as principal. > 4. When I change one-way method to have input and output messages defined in WSDL and update implementation accordingly it suprisingly starts to work as expected. > It's quite serious issue, because currently there's no way to have authorized access to oneway webservice methods. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4289) Authentication bug on one-way JAX-WS methods

by Jakub Grabowski (JIRA)

Jakub Grabowski created WFLY-4289: ------------------------------------- Summary: Authentication bug on one-way JAX-WS methods Key: WFLY-4289 URL: https://issues.jboss.org/browse/WFLY-4289 Project: WildFly Issue Type: Bug Components: Security, Web Services Affects Versions: 8.2.0.Final Reporter: Jakub Grabowski Assignee: Darran Lofthouse 1. For two-way methods basic authentication and autorization works fine. User is authenticated with LDAP module and gets proper role that autorizes invocation. It works just fine. By two-way method I mean method with input and output message defined in WSDL. 2. For one-way methods (return type void) user is not authenticated properly. It results in denial of method invocation. 3. When I remove @RolesAllowed declaration I can see that for two-way methods authentication is correct (pricipal is set to logged user), but for one-way it's not - I get "anonymous" as principal. 4. When I change one-way method to have input and output messages defined in WSDL and update implementation accordingly it suprisingly starts to work as expected. It's quite serious issue, because currently there's no way to have authorized access to oneway webservice methods. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3769) Implement graceful shutdown for batch tasks

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/WFLY-3769?page=com.atlassian.jira.plugin.... ] James Perkins reassigned WFLY-3769: ----------------------------------- Assignee: James Perkins (was: Jason Greene) > Implement graceful shutdown for batch tasks > ------------------------------------------- > > Key: WFLY-3769 > URL: https://issues.jboss.org/browse/WFLY-3769 > Project: WildFly > Issue Type: Sub-task > Components: Batch > Reporter: Stuart Douglas > Assignee: James Perkins > > This should make sure that all batch jobs have completed before the container shuts down, and not allow new jobs to start while the container is suspended. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 5 months

1
0
0 / 0

[JBoss JIRA] (SECURITY-868) Multithread issue when validate with cached hased password + nonce credential info from JBossCachedAuthenticationManager

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/SECURITY-868?page=com.atlassian.jira.plug... ] RH Bugzilla Integration commented on SECURITY-868: -------------------------------------------------- Kabir Khan <kkhan(a)redhat.com> changed the Status of [bug 1181084|https://bugzilla.redhat.com/show_bug.cgi?id=1181084] from NEW to ON_QA > Multithread issue when validate with cached hased password + nonce credential info from JBossCachedAuthenticationManager > -------------------------------------------------------------------------------------------------------------------------- > > Key: SECURITY-868 > URL: https://issues.jboss.org/browse/SECURITY-868 > Project: PicketBox > Issue Type: Task > Components: PicketBox > Reporter: Jim Ma > Assignee: Stefan Guilhen > Fix For: PicketBox_4_9_0.Beta3 > > > When the new security domain is configured with catch-type=default in standalone.xml, the validated credential will be put in the JBossCachedAuthenticationManager with principal and domaininfo value pair. In multithread environment, a new validated credential can overwrite the previous thread cached domain info. This will cause even in the same thread , the cached authentication info could not work. For example if one user login with username , password and nonce in two threads : thread A and thread B ;thread A caches the validated credential(hased password +nonce) in JBossCachedAuthenticationMessager, thread B does the authentication, then caches the validated credential (hashed password + nonce) , even it's the same user and passoword, the credential is different because the nonce is diffrent. So the new credential created in thread B will overwrite the previous value created by thread A . So in thread A, the cached validation info won't work and following validation with cached credential will all fail. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 5 months

1
0
0 / 0

[JBoss JIRA] (SECURITY-866) Add jboss module option to ServerLoginModule

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/SECURITY-866?page=com.atlassian.jira.plug... ] RH Bugzilla Integration commented on SECURITY-866: -------------------------------------------------- Kabir Khan <kkhan(a)redhat.com> changed the Status of [bug 1181086|https://bugzilla.redhat.com/show_bug.cgi?id=1181086] from MODIFIED to ON_QA > Add jboss module option to ServerLoginModule > -------------------------------------------- > > Key: SECURITY-866 > URL: https://issues.jboss.org/browse/SECURITY-866 > Project: PicketBox > Issue Type: Task > Components: PicketBox > Reporter: Jim Ma > Assignee: Jim Ma > > If the callback class isn't in the picketbox module or the deployment module, there is module option can be provided to define the module path for the callback class or validator class. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 5 months

1
0
0 / 0

[JBoss JIRA] (SECURITY-866) Add jboss module option to ServerLoginModule

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/SECURITY-866?page=com.atlassian.jira.plug... ] RH Bugzilla Integration commented on SECURITY-866: -------------------------------------------------- baranowb <bbaranow(a)redhat.com> changed the Status of [bug 1181086|https://bugzilla.redhat.com/show_bug.cgi?id=1181086] from NEW to MODIFIED > Add jboss module option to ServerLoginModule > -------------------------------------------- > > Key: SECURITY-866 > URL: https://issues.jboss.org/browse/SECURITY-866 > Project: PicketBox > Issue Type: Task > Components: PicketBox > Reporter: Jim Ma > Assignee: Jim Ma > > If the callback class isn't in the picketbox module or the deployment module, there is module option can be provided to define the module path for the callback class or validator class. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 5 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-185) ClassCastException at ConditionEvaluator

by Liu Yan (JIRA)

[ https://issues.jboss.org/browse/DROOLS-185?page=com.atlassian.jira.plugin... ] Liu Yan updated DROOLS-185: --------------------------- 5.5.0.final.regards. -------------------------------- 来自我的新浪邮箱android客户端 -------- 原始邮件 -------- 发件人:Davide Sottara (JIRA) 时间:2015年1月23日 13:01(星期五) 收件人:oscar_cqu@sina.com 主题:[JBoss JIRA] (DROOLS-185) ClassCastException at ConditionEvaluator Davide Sottara commented on DROOLS-185 Re: ClassCastException at ConditionEvaluator Which version are you using? This should have been fixed in recent versions Add Comment This message was sent by Atlassian JIRA (v6.3.11#6341-sha1:83c4d29) > ClassCastException at ConditionEvaluator > ---------------------------------------- > > Key: DROOLS-185 > URL: https://issues.jboss.org/browse/DROOLS-185 > Project: Drools > Issue Type: Bug > Affects Versions: 5.5.0.Final > Reporter: Sergey Alaev > Assignee: Mario Fusco > > Stacktrace: > Caused by: java.lang.ClassCastException: ***** cannot be cast to ****** > at ConditionEvaluator443abf2927ca4f64a4ad86407ae34799.evaluate(Unknown Source) > at org.drools.rule.constraint.MvelConstraint.evaluate(MvelConstraint.java:200) > at org.drools.rule.constraint.MvelConstraint.isAllowed(MvelConstraint.java:157) > at org.drools.reteoo.FromNode.checkConstraintsAndPropagate(FromNode.java:318) > at org.drools.reteoo.FromNode.assertLeftTuple(FromNode.java:164) > at org.drools.reteoo.CompositeLeftTupleSinkAdapter.doPropagateAssertLeftTuple(CompositeLeftTupleSinkAdapter.java:232) > at org.drools.reteoo.CompositeLeftTupleSinkAdapter.createAndPropagateAssertLeftTuple(CompositeLeftTupleSinkAdapter.java:116) > at org.drools.reteoo.LeftInputAdapterNode.assertObject(LeftInputAdapterNode.java:154) > at org.drools.reteoo.SingleObjectSinkAdapter.propagateAssertObject(SingleObjectSinkAdapter.java:59) > Reason: > ConditionEvaluator seems to be using lazy initializing and then caches generated class to evaluate this expression with another arguments. > Given following: > interface A { > String getString(); > } > interface B { > String getString(); > } > class X implements B, A {} > class Y implements A{} > rule "test rule" > when: > A(string != null) > then: > end > When rule engine is called for the first time with instance of class X, ConditionEvaluator will bind itself to first found interface implementing method getString(), i.e. interface B. > Thus second call with instance of class Y will cause ClassCastException of casting Y to B. > Solution: force MVEL to bind bytecode generated methods to class/interface declared in the rule explicitly, in our case - to interface A. > Quickfix: use following declaration of class X: > class X implements A, B {} > Because ConditionEvaluator binds to first available interface, it will bind now to correct interface - to interface A. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1721) AUTH and ENCRYPT protocols configured with plain text passwords

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/JGRP-1721?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on JGRP-1721: ----------------------------------------------- Misha H. Ali <mhusnain(a)redhat.com> changed the Status of [bug 1021819|https://bugzilla.redhat.com/show_bug.cgi?id=1021819] from VERIFIED to RELEASE_PENDING > AUTH and ENCRYPT protocols configured with plain text passwords > --------------------------------------------------------------- > > Key: JGRP-1721 > URL: https://issues.jboss.org/browse/JGRP-1721 > Project: JGroups > Issue Type: Bug > Affects Versions: 3.4 > Reporter: Martin Gencur > Assignee: Bela Ban > Fix For: 3.5 > > > The following parameters of AUTH protocol are stored as plain text: > * keystore_password > The following parameters of ENCRYPT protocol are stored as plain text: > * store_password > * key_password > Example: > {code} > <ENCRYPT key_store_name="defaultStore.keystore" store_password="changeit" alias="myKey"/> > {code} > Requirements for storing passwords: https://docspace.corp.redhat.com/docs/DOC-131628 -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4171) Provide an html5 archetype for wildfly

by Rafael Benevides (JIRA)

[ https://issues.jboss.org/browse/WFLY-4171?page=com.atlassian.jira.plugin.... ] Rafael Benevides commented on WFLY-4171: ---------------------------------------- New repo: https://repository.jboss.org/nexus/content/repositories/jboss_releases_st... > Provide an html5 archetype for wildfly > -------------------------------------- > > Key: WFLY-4171 > URL: https://issues.jboss.org/browse/WFLY-4171 > Project: WildFly > Issue Type: Feature Request > Reporter: Fred Bricon > Assignee: Rafael Benevides > > We'd like to provide a Wildfly-ified version of the html5 archetype in JBoss Central, for JBoss Tools and Developer Studio, The current versions we serve right now are : > * org.jboss.aerogear.archetypes:jboss-html5-mobile-archetype:7.1.3.Final > * org.jboss.archetype.wfk:jboss-html5-mobile-archetype:2.6.0.Final -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4171) Provide an html5 archetype for wildfly

by Rafael Benevides (JIRA)

[ https://issues.jboss.org/browse/WFLY-4171?page=com.atlassian.jira.plugin.... ] Rafael Benevides commented on WFLY-4171: ---------------------------------------- [~fbricon] New repo with fixed ${packagePath}: https://repository.jboss.org/nexus/content/repositories/jboss_releases_st... Sorry for taking so long. > Provide an html5 archetype for wildfly > -------------------------------------- > > Key: WFLY-4171 > URL: https://issues.jboss.org/browse/WFLY-4171 > Project: WildFly > Issue Type: Feature Request > Reporter: Fred Bricon > Assignee: Rafael Benevides > > We'd like to provide a Wildfly-ified version of the html5 archetype in JBoss Central, for JBoss Tools and Developer Studio, The current versions we serve right now are : > * org.jboss.aerogear.archetypes:jboss-html5-mobile-archetype:7.1.3.Final > * org.jboss.archetype.wfk:jboss-html5-mobile-archetype:2.6.0.Final -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 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-jira January 2015