February 2017 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFCORE-2257) Missing username in LDAP entry for legacy ldap realm returns 500 instead of 401

by Ondrej Lukas (JIRA)

Ondrej Lukas created WFCORE-2257: ------------------------------------ Summary: Missing username in LDAP entry for legacy ldap realm returns 500 instead of 401 Key: WFCORE-2257 URL: https://issues.jboss.org/browse/WFCORE-2257 Project: WildFly Core Issue Type: Bug Components: Security Reporter: Ondrej Lukas Assignee: Darran Lofthouse In case when legacy LDAP Realm uses {{username-load}} attribute and its value does not exist in LDAP entry then current implementation returns status code 500. This is different behaviour from EAP 7.0.x where status code 401 is returned. This issue can be related to JBEAP-8106 (500 return for nonexistent user in legacy ldap security realm). [~dlofthouse] should it be handled as blocker due to regression or is this change intended and we should just cover this change only in release notes? -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3858) Infinispan cache configuration is not always applied to security-domain

by Hisanobu Okuda (JIRA)

[ https://issues.jboss.org/browse/WFLY-3858?page=com.atlassian.jira.plugin.... ] Hisanobu Okuda updated WFLY-3858: --------------------------------- > Infinispan cache configuration is not always applied to security-domain > ----------------------------------------------------------------------- > > Key: WFLY-3858 > URL: https://issues.jboss.org/browse/WFLY-3858 > Project: WildFly > Issue Type: Bug > Components: Security > Affects Versions: 8.1.0.Final > Reporter: Robert Tuck > Assignee: Darran Lofthouse > Attachments: debugger output.txt > > > On Wildfly 8.1.0.Final, I have the following standalone-ha.xml: > <subsystem xmlns="urn:jboss:domain:infinispan:2.0"> > ... > <cache-container name="security" default-cache="auth-cache" start="EAGER"> > <transport cluster="${cluster.name}_SEC" lock-timeout="60000"/> > <replicated-cache name="auth-cache" batching="true" mode="ASYNC"> > <eviction strategy="LRU" max-entries="10000"/> > <expiration lifespan="60000"/> > </replicated-cache> > </cache-container> > </subsystem> > ... > <subsystem xmlns="urn:jboss:domain:security:1.2"> > <security-domains> > ... > <security-domain name="OAuth-Consumer" cache-type="infinispan"> > <authentication> > <login-module code="com.idbs.ewb.server.auth.module.OAuthConsumerLoginModule" flag="sufficient" > module="deployment.ewb-server-ear.ear"> > <module-option name="allowedConsumerAuthFailures" value="-1"/> > <module-option name="consumerLoginFailureTimeoutMs" value="3000"/> > </login-module> > </authentication> > </security-domain> > </security-domains> > </subsystem> > After startup the OAuth-Consumer security domain cache "auth-cache" is not always configured with the specified settings (~50% of the time). This can be verified by monitoring the jboss.infinispan nodes with JConsole and retrieving the cache settings, and tracking the cache hits during logins. This shows that succesful logins are cached but do not expire after the expected 60s, and that the expiration lifespan is set to -1 rather than 60000, as are eviction max entries. > After some debugging I have narrowed down the problem to some code that gets called from inside org.jboss.as.security.plugins.JNDIBasedSecurityManagement: > public SecurityDomainContext createSecurityDomainContext(String securityDomain, Object cacheFactory) throws Exception { > log.debugf("Creating SDC for domain=" + securityDomain); > AuthenticationManager am = createAuthenticationManager(securityDomain); > // create authentication cache > if (cacheFactory instanceof EmbeddedCacheManager) { > EmbeddedCacheManager cacheManager = EmbeddedCacheManager.class.cast(cacheFactory); > @SuppressWarnings("rawtypes") > Cache cache = null; > if (cacheManager != null) { > // TODO override global settings with security domain specific > ConfigurationBuilder builder = new ConfigurationBuilder(); > Configuration baseCfg = cacheManager.getCacheConfiguration("auth-cache"); > ^^^^ This call here doesn’t always return the correct configuration, baseCfg is then null. > if (baseCfg != null) { > builder.read(baseCfg); > } > cacheManager.defineConfiguration(securityDomain, builder.build()); > cache = cacheManager.getCache(securityDomain); > } > if (cache != null && am instanceof CacheableManager) { > @SuppressWarnings({ "unchecked", "rawtypes" }) > CacheableManager<Map, Principal> cm = (CacheableManager<Map, Principal>) am; > cm.setCache(cache); > } > } else if (cacheFactory instanceof DefaultAuthenticationCacheFactory) { > <…> > } > getCacheConfiguration(String) is implemented inside org.infinispan.manager.DefaultCacheManager: > @Override > public Configuration getCacheConfiguration(String name) { > Configuration configuration = configurationOverrides.get(name); > if (configuration == null && cacheExists(name)) { > return defaultConfiguration; > } > return configuration; > } > Seems like the condition configuration == null occurs when the cache doesn’t exist, therefore it returns null. This appears to be a race condition between this code and where it gets registered in wireAndStartCache(String). > -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2253) Some AttributeDefinition instances are configured with default values but say they are required

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2253?page=com.atlassian.jira.plugi... ] Brian Stansberry reassigned WFCORE-2253: ---------------------------------------- Assignee: Brian Stansberry > Some AttributeDefinition instances are configured with default values but say they are required > ----------------------------------------------------------------------------------------------- > > Key: WFCORE-2253 > URL: https://issues.jboss.org/browse/WFCORE-2253 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Reporter: Brian Stansberry > Assignee: Brian Stansberry > > An AD with a default value does not require the user to set it, so configuring it with required = true fka allowNull = false is incorrect. WFCORE-2252 proposes to reject these. This is to clean them up first. > Note that for any such attributes, if they existed in a previous release a transformer must be written to go along with a change to required=false. Even though they had a default before, the required=true setting made it as if it didn't exist, so this change is the same as adding a default -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-8010) Write a test for DataSources with Elytron

by Flavia Rainone (JIRA)

Flavia Rainone created WFLY-8010: ------------------------------------ Summary: Write a test for DataSources with Elytron Key: WFLY-8010 URL: https://issues.jboss.org/browse/WFLY-8010 Project: WildFly Issue Type: Enhancement Components: JCA Reporter: Flavia Rainone Assignee: Stefano Maestri Write a basic test case to make sure everything needed to make DataSources + Elytron work is in place. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-8007) Replace WorkManager elytron-enabled atttribute by elytron-security-domain

by Flavia Rainone (JIRA)

[ https://issues.jboss.org/browse/WFLY-8007?page=com.atlassian.jira.plugin.... ] Flavia Rainone reassigned WFLY-8007: ------------------------------------ Assignee: James Perkins (was: Stefano Maestri) [~jamezp], do you think you will have time to look into this other Capability-related issue before the next release? Let me know if that's not the case, either I or [~maeste] will work on this Jira. Thanks a lot! > Replace WorkManager elytron-enabled atttribute by elytron-security-domain > ------------------------------------------------------------------------- > > Key: WFLY-8007 > URL: https://issues.jboss.org/browse/WFLY-8007 > Project: WildFly > Issue Type: Enhancement > Components: JCA > Reporter: Flavia Rainone > Assignee: James Perkins > > Right now the elytron-enabled attribute does not allow the dependency on the security domain capability. We need to replace it by elytron-security-domain and have the capability dependency sorted out. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1620) Upgrade slf4j from version 1.7.7.jbossorg-1 to 1.7.22

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1620?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-1620: ------------------------------------- Fix Version/s: 2.2.1.Final > Upgrade slf4j from version 1.7.7.jbossorg-1 to 1.7.22 > ----------------------------------------------------- > > Key: WFCORE-1620 > URL: https://issues.jboss.org/browse/WFCORE-1620 > Project: WildFly Core > Issue Type: Component Upgrade > Components: Logging > Reporter: James Perkins > Assignee: Frank Langelage > Fix For: 3.0.0.Alpha18, 2.2.1.Final > > > There should no longer be a need for the forked version. The fix for [SLF4J-167|http://jira.qos.ch/browse/SLF4J-167] should be in version 1.7.14 with some additional fixes for replaying the previously lost logs. > [Quote from comment on JIRA|http://jira.qos.ch/browse/SLF4J-167?focusedCommentId=17048&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17048] > {quote} > The problem of lost logs during initialization in a multi-threaded application is solved by storing and replaying the logs which would be otherwise lost. Fix available in SLF4J version 1.7.15. > {quote} > Analysis will need to be done to ensure this works as expected before the fork is no longer required. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-8009) Write a test for Resource Adapters using Elytron

by Flavia Rainone (JIRA)

Flavia Rainone created WFLY-8009: ------------------------------------ Summary: Write a test for Resource Adapters using Elytron Key: WFLY-8009 URL: https://issues.jboss.org/browse/WFLY-8009 Project: WildFly Issue Type: Enhancement Components: JCA Reporter: Flavia Rainone Write a basic test case to make sure everything needed to make Resource Adapters + Elytron work is in place. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2256) Undertow 1.4.10.Final

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2256?page=com.atlassian.jira.plugi... ] Brian Stansberry reassigned WFCORE-2256: ---------------------------------------- Fix Version/s: 3.0.0.Alpha23 Assignee: Stuart Douglas Resolution: Done > Undertow 1.4.10.Final > --------------------- > > Key: WFCORE-2256 > URL: https://issues.jboss.org/browse/WFCORE-2256 > Project: WildFly Core > Issue Type: Component Upgrade > Reporter: Stuart Douglas > Assignee: Stuart Douglas > Fix For: 3.0.0.Alpha23 > > -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1987) Create request/response reporting mechanism

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1987?page=com.atlassian.jira.plugi... ] Brian Stansberry commented on WFCORE-1987: ------------------------------------------ I would expect getDomainResults to return an undefined node for a write-attribute call. The key thing is it's concerned with the *result* child of the response that goes to the user, not the complete response. The result of a write-attribute is 'undefined': {code} { "outcome" => "success", "result" => undefined } {code} Does the A2 node have the warnings you expect? If so you'll need to propagate those to A1 by reading them from A2 and calling context.addWarning, similarly to how it currently reads the result from A2 and passes it to A1 by calling context.getResult().set(...) What needs thought is how to deal with warnings that come from slave HCs and from the servers as part of domain rollout. My impression from your comments is that in the case of servers, the 'server-results' structure is showing the warnings from the servers, as part of each server's response. Correct? If so, that sounds ok. For these domain rollout ops, I think it's fine to ignore warnings from the slave HCs. They should be redundant, same as what the master generated in your A2 response. All this is about ops that result in a domain-wide rollout (i.e. that go the OperationCoordinatorStepHandler.executeTwoPhaseOperation path). This feature also needs to deal with ops that go the executeDirect path or that are proxied steps in a composite that goes the executeTwoPhaseOperation. That is /host=slave:do-something-that-generates-a-warn or /host=slave/server=a:do-something-that-generates-a-warn or /host=master/server=a:do-something-that-generates-a-warn Aha! It looks like that is largely handled. See ProxyStepHandler L199-201 -- any headers from the proxied process are copied into the local response. This will all need to be verified via tests. > Create request/response reporting mechanism > ------------------------------------------- > > Key: WFCORE-1987 > URL: https://issues.jboss.org/browse/WFCORE-1987 > Project: WildFly Core > Issue Type: Enhancement > Components: Remoting > Reporter: Radim Hatlapatka > Assignee: Bartosz Baranowski > Labels: downstream_dependency > > In certain cases it is useful to send back, to client, some sort of context information about the outcome of operation. For instance, when change in configuration warrants another one and without it, after reload/restart server could not operate properly. For instance JBEAP-7284. > Scope of this enhancement are: > a) way to send back information > b) control level of "information" - just like in case of loggers > a) Information will be sent in response headers, under "warnings" key. Each entry, "warning" will contain operation, address, level/severity and i18n string with proper ID. > b) default level threshold would be "WARNING", if user requires more detailed information, he can request it via operation-headers->warninig-level > Example: > {noformat} > { > "outcome" => "success", > "response-headers" => { > "warnings" => [ > { > "warning" => "WFLYCTL0436: Couldn't convert 'XXX' into proper warning level, threshold falling back to 'ALL'. Possible values: SEVERE,WARNING,INFO,CONFIG,FINE,FINER,FINEST", > "level" => "ALL", > "operation" => { > "address" => [ > ("subsystem" => "undertow"), > ("server" => "default-server"), > ("http-listener" => "default") > ], > "operation" => "write-attribute" > } > }, > { > "warning" => "WFLYUT0090: Worker used in http-listener: 'puppet-master', must be used in remoting subsystem.", > "level" => "WARNING", > "operation" => { > "address" => [ > ("subsystem" => "undertow"), > ("server" => "default-server"), > ("http-listener" => "default") > ], > "operation" => "write-attribute" > } > } > ], > "operation-requires-reload" => true, > "process-state" => "reload-required" > } > } > {noformat} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2238) Drop the inflowed security domains attribute from access=identity

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2238?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-2238: ------------------------------------- Git Pull Request: https://github.com/wildfly/wildfly-core/pull/2143 (was: https://github.com/wildfly/wildfly-core/pull/2134) > Drop the inflowed security domains attribute from access=identity > ----------------------------------------------------------------- > > Key: WFCORE-2238 > URL: https://issues.jboss.org/browse/WFCORE-2238 > Project: WildFly Core > Issue Type: Task > Components: Domain Management, Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Priority: Critical > Fix For: 3.0.0.Alpha23 > > > We may restore it later so don't remove the code that uses it but remove it from the management model. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira February 2017