April 2014 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-3200) Support Jackson 2 out of the box

by Nathaniel A. Johnson (JIRA)

Nathaniel A. Johnson created WFLY-3200: ------------------------------------------ Summary: Support Jackson 2 out of the box Key: WFLY-3200 URL: https://issues.jboss.org/browse/WFLY-3200 Project: WildFly Issue Type: Feature Request Security Level: Public (Everyone can see) Components: REST Reporter: Nathaniel A. Johnson Assignee: Stuart Douglas Priority: Minor Wildfly can be configured to allow access to the native Jackson API. In order to accomplish this, you have to add a jboss-deployment-structure.xml that contains the following: <jboss-deployment-structure> <deployment> <exclusions> <module name="org.jboss.resteasy.resteasy-jackson-provider"/> </exclusions> <dependencies> <module name="org.jboss.resteasy.resteasy-jackson2-provider" services="import"/> </dependencies> </deployment> </jboss-deployment-structure> It would be better if Jackson 2 were the default provider and this were not necessary. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-3048) "Local" authentication fails when LDAP is used for ManagementRealm

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFLY-3048?page=com.atlassian.jira.plugin.... ] Darran Lofthouse commented on WFLY-3048: ---------------------------------------- Unfortunately the LDAP authorization configuration is omitted so it is difficult to see how exactly that was defined, when testing was performed to define a different username for the local mechanism that should match in LDAP group loading one thing that could have been missing is the <username-to-dn /> definition in the <ldap /> section of <authorization />. The purpose of that section is to define how to take the username from a non-ldap based authentication and convert it into a distinguished name, unless force is specified typically we would skip the second search and use a cached result from the ldap based authentication but of course that is not possible if the mechanism used was <local /> Regarding the general problem I am going to add a new attribute skip-group-loading="..." with a default of 'false' to the <local /> element within <authentication /> - if this attribute is set to true then provided the local mechanism was used for authentication then the group loading step will be skipped. Note: A default of true may make more sense for this attribute, unfortunately we have already shipped where that is not the default setting and users could be relying on us performing group loading so we will need the default value to be 'false' - in the config we ship however we can set this to true. > "Local" authentication fails when LDAP is used for ManagementRealm > ------------------------------------------------------------------ > > Key: WFLY-3048 > URL: https://issues.jboss.org/browse/WFLY-3048 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Security > Affects Versions: 8.0.0.Final > Environment: Ubuntu 13.04, Xeon-based VPS > Reporter: Matt Jensen > Assignee: Darran Lofthouse > Fix For: 8.0.1.Final > > > When LDAP is used for authentication in ManagementRealm, "local" authentication, which is enabled in configuration for the realm, appears to stop working. > I have configured my ManagementRealm to use LDAP for authentication of remote clients. However, I also need to allow local authentication without a username and password, for when jboss-cli is invoked from the command line on the server. This is needed in order for the wildfly-init-debian.sh script to shut down the server. I have configured the ManagementRealm as follows: > <security-realm name="ManagementRealm"> > <authentication> > <local default-user="$local" /> > <ldap connection="..." base-dn="ou=accounts,dc=..." recursive="false"> > ... > </ldap> > </authentication> > <authorization map-groups-to-roles="false"> > <ldap connection="..."> > ... > </ldap> > </authorization> > </security-realm> > I left out most of the LDAP configuration because I don't think it is important for this issue. LDAP authentication works fine for remote clients. In fact, it works fine for local clients as well--when I invoke jboss-cli with LDAP authentication enabled, it prompts for a username and password; if I enter a valid combination from the LDAP directory, jboss-cli connects successfully and executes its command. > The problem is that I need it to NOT prompt for a username and password when jboss-cli is invoked locally. Which, I believe, is how things are supposed to work when "local" authentication is also enabled; it just doesn't work that way when LDAP is enabled for the same realm. > If I comment out the <ldap .../> element in <authentication> for the realm, local authentication starts working again. I can invoke jboss-cli locally and the command is carried out without a username and password prompt. Re-enable LDAP, with no other configuration changes, and again it flips back to requiring a username and password. > I have tried replacing "$local" in the @default-user element of the <local> element with a valid name from the LDAP directory, both as a simple username and as a full DN, and jboss-cli still prompts for a username and password. > The modification date on the [tmp/auth] directory changes when I run jboss-cli with LDAP in place and get the username/password prompt, so it appears that the client is putting a token in there to try to use local authentication. The server just never picks it up. > The documentation specifically mentions that <local/> should work along with <ldap/> here: > https://docs.jboss.org/author/display/WFLY8/Security+Realms -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-3199) Remove external BOM from jboss-as-parent

by Paul Gier (JIRA)

Paul Gier created WFLY-3199: ------------------------------- Summary: Remove external BOM from jboss-as-parent Key: WFLY-3199 URL: https://issues.jboss.org/browse/WFLY-3199 Project: WildFly Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Build System Reporter: Paul Gier Assignee: Paul Gier Fix For: 8.0.1.Final The jboss-as-parent pom currently depends on an external BOM (apacheds-parent) to get some dependency versions. This means that it's not obvious which version is used for some dependencies. And it's possible that a version could be unintentionally upgraded. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-2553) Enable SPNEGO Authentication

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFLY-2553?page=com.atlassian.jira.plugin.... ] Darran Lofthouse updated WFLY-2553: ----------------------------------- Fix Version/s: 8.0.1.Final (was: 9.0.0.CR1) > Enable SPNEGO Authentication > ---------------------------- > > Key: WFLY-2553 > URL: https://issues.jboss.org/browse/WFLY-2553 > Project: WildFly > Issue Type: Sub-task > Security Level: Public(Everyone can see) > Components: Web (Undertow) > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Labels: web_security > Fix For: 8.0.1.Final > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-3197) ExternalContextFactory cuts context from deployment context/requires dependency on module

by David Lloyd (JIRA)

[ https://issues.jboss.org/browse/WFLY-3197?page=com.atlassian.jira.plugin.... ] David Lloyd commented on WFLY-3197: ----------------------------------- What ExternalContextFactory are we talking about? Please qualify with package name. > ExternalContextFactory cuts context from deployment context/requires dependency on module > ----------------------------------------------------------------------------------------- > > Key: WFLY-3197 > URL: https://issues.jboss.org/browse/WFLY-3197 > Project: WildFly > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Components: Naming > Affects Versions: 8.0.0.Final, 8.0.1.Final > Reporter: Bartosz Baranowski > Assignee: Bartosz Baranowski > Fix For: 8.0.1.Final > > > WFLY-2777 changed CCL for context creation(if module is set in external context factory). This essentially cuts context from deployment classes during creation time. This can cause problems when external-context-factory.module classes (ObjectFactories, etc) require deployment classes to be visible from classloader which created context( external-context.module ) and are not found. > Steps to reproduce: > 1. define isolated module IM ( with classloader IM_CL ) > 2. create external-context-factory with module set to IM > 3. create some deployment with interface, for which proxies should be looked up via external-context ( with classloader D_CL ) - deployment has no dependency on IM, since it may contain legacy classes or unwanted dependencies > 4. lookup and invoke proxy > Now what will happen is during deployment external-context will be spawned just fine. However, the runtime outcome wont be pleasing. > Case 1: application and custom context dont do CCL magic > - invocation happen in deployment CCL, hence IM_CL classes are not visible and no classes required for deserialization can be loaded, this will fail ( return javax.naming.Reference instance, since ObjectFactory from IM_CL cant be found ) > Case 2: application or custom context switch CCL to IM_CL for lookup > - CCL is set to IM_CL, ObjectFactory can be found, but D_CL classes cant, hence some naming error probably > Neither of above will work, unless IM_CL and D_CL have some sort of dependency on each other, which just makes module CL configured in external-context-factory irrelevant, since D_CL will require dependency on IM_CL. > Workaround: > yes, store IM_CL in context wrapper and upon first invocation obtain CCL( hopefuly D_CL), create agregating CL and set it as CCL for each context invocation. > Possible fix: > 1. pass D_CL and IM_CL as part of env to factory, to allow context/context-wrapper to do some magic > 2. alter ExternalContextFactory and create agregating/delegating CL, which will just iterate over IM_CL and D_CL if present to load proper classes -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (SECURITY-813) Update the KerberosLoginModule for delegated identity.

by Darran Lofthouse (JIRA)

Darran Lofthouse created SECURITY-813: ----------------------------------------- Summary: Update the KerberosLoginModule for delegated identity. Key: SECURITY-813 URL: https://issues.jboss.org/browse/SECURITY-813 Project: PicketBox Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Negotiation Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: Negotiation_2_3_0_Final The KerberosLoginModule should also provide an option to populate the Subject using the delegated credential. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-3198) Reenabling an application prevents it from deployement after a restart

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-3198?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-3198: ----------------------------------------------- Emmanuel Hugonnet (ehsavoie) <ehugonne(a)redhat.com> changed the Status of [bug 1074999|https://bugzilla.redhat.com/show_bug.cgi?id=1074999] from NEW to ASSIGNED > Reenabling an application prevents it from deployement after a restart > ---------------------------------------------------------------------- > > Key: WFLY-3198 > URL: https://issues.jboss.org/browse/WFLY-3198 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: ConfigAdmin > Affects Versions: 8.0.0.Final > Reporter: Emmanuel Hugonnet > Assignee: Emmanuel Hugonnet > > After disabling and then re-enabling the application, I don't see Application.war.deployed; I still see Application.war.undeployed. > That explains why it doesn't get deployed after restart. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-3198) Reenabling an application prevents it from deployement after a restart

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-3198?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated WFLY-3198: ------------------------------------------ Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1074999 > Reenabling an application prevents it from deployement after a restart > ---------------------------------------------------------------------- > > Key: WFLY-3198 > URL: https://issues.jboss.org/browse/WFLY-3198 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: ConfigAdmin > Affects Versions: 8.0.0.Final > Reporter: Emmanuel Hugonnet > Assignee: Emmanuel Hugonnet > > After disabling and then re-enabling the application, I don't see Application.war.deployed; I still see Application.war.undeployed. > That explains why it doesn't get deployed after restart. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-3198) Reenabling an application prevents it from deployement after a restart

by Emmanuel Hugonnet (JIRA)

Emmanuel Hugonnet created WFLY-3198: --------------------------------------- Summary: Reenabling an application prevents it from deployement after a restart Key: WFLY-3198 URL: https://issues.jboss.org/browse/WFLY-3198 Project: WildFly Issue Type: Bug Security Level: Public (Everyone can see) Components: ConfigAdmin Affects Versions: 8.0.0.Final Reporter: Emmanuel Hugonnet Assignee: Emmanuel Hugonnet After disabling and then re-enabling the application, I don't see Application.war.deployed; I still see Application.war.undeployed. That explains why it doesn't get deployed after restart. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-2883) ManagementResourceRegistration.getOverrideModel never returns null

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFLY-2883?page=com.atlassian.jira.plugin.... ] Brian Stansberry updated WFLY-2883: ----------------------------------- Fix Version/s: 9.0.0.CR1 (was: 8.0.1.Final) > ManagementResourceRegistration.getOverrideModel never returns null > ------------------------------------------------------------------ > > Key: WFLY-2883 > URL: https://issues.jboss.org/browse/WFLY-2883 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Domain Management > Reporter: Brian Stansberry > Assignee: Brian Stansberry > Fix For: 9.0.0.CR1 > > > ManagementResourceRegistration.getOverrideModel ends up returning the wildcard registration if there is no override registration. This isn't correct. > The fix isn't trivial because fixing it results in nasty failures in the smoke tests. From looking at the uses of this method (which all involve a null check) I assume there are some bugs in the code that calls this method that get exposed once it does what it should. > This bug is the cause of the initial failure of my WFLY-2880 fix. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 1 month

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira April 2014