November 2016 - jboss-jira - Jboss List Archives

[JBoss JIRA] (ELY-715) SPNEGO: missing negstat field in the first reply

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/ELY-715?page=com.atlassian.jira.plugin.sy... ] Jan Kalina closed ELY-715. -------------------------- Resolution: Won't Fix This is known bug of JDK/GSSAPI spec: http://cr.openjdk.java.net/~weijun/spec/updates-error-token.txt - wont fix for now. > SPNEGO: missing negstat field in the first reply > ------------------------------------------------ > > Key: ELY-715 > URL: https://issues.jboss.org/browse/ELY-715 > Project: WildFly Elytron > Issue Type: Bug > Components: Authentication Mechanisms > Reporter: Jan Kalina > Assignee: Jan Kalina > > When the client sends an initial SPNEGO token with Kerberos as preferred mechanism and includes an invalid kerberos token, then client expects to see the {{WWW-Authenticate}} HTTP header with SPNEGO response {{negTokenResp[ negState = reject ]}}. > As stated in [SPNEGO specification|https://tools.ietf.org/html/rfc4178#section-4.2.2] negstat is required in first reply: > {code:borderStyle=dashed} > negState > ... > This field is REQUIRED in the first reply from the target, and is > OPTIONAL thereafter. When negState is absent, the actual state > should be inferred from the state of the negotiated mechanism > context. > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7462) Do not log common CLI failures for Elytron to server log

by Ondrej Lukas (JIRA)

Ondrej Lukas created WFLY-7462: ---------------------------------- Summary: Do not log common CLI failures for Elytron to server log Key: WFLY-7462 URL: https://issues.jboss.org/browse/WFLY-7462 Project: WildFly Issue Type: Bug Components: Security Reporter: Ondrej Lukas Assignee: Darran Lofthouse Priority: Critical Almost every common CLI command failure from Elytron subsystem is logged as ERROR to server log. For example this means: * trying to add duplicate resource -> ERROR in server log * missing required attribute of any resource attribute in CLI command -> ERROR in server log * missing capability -> ERROR in server log * ... Some reasons why these logs should not be logged to server log: * Adding useless messages to server log. * This is inconsistent with other subsystems (e.g. PicketBox). It can be confusing. These common CLI command failures should be removed from the log, or logged on low level (i.e. DEBUG) -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7462) Do not log common CLI failures for Elytron to server log

by Ondrej Lukas (JIRA)

[ https://issues.jboss.org/browse/WFLY-7462?page=com.atlassian.jira.plugin.... ] Ondrej Lukas updated WFLY-7462: ------------------------------- Affects Version/s: 11.0.0.Alpha1 > Do not log common CLI failures for Elytron to server log > -------------------------------------------------------- > > Key: WFLY-7462 > URL: https://issues.jboss.org/browse/WFLY-7462 > Project: WildFly > Issue Type: Bug > Components: Security > Affects Versions: 11.0.0.Alpha1 > Reporter: Ondrej Lukas > Assignee: Darran Lofthouse > Priority: Critical > Labels: user_experience > > Almost every common CLI command failure from Elytron subsystem is logged as ERROR to server log. For example this means: > * trying to add duplicate resource -> ERROR in server log > * missing required attribute of any resource attribute in CLI command -> ERROR in server log > * missing capability -> ERROR in server log > * ... > Some reasons why these logs should not be logged to server log: > * Adding useless messages to server log. > * This is inconsistent with other subsystems (e.g. PicketBox). It can be confusing. > These common CLI command failures should be removed from the log, or logged on low level (i.e. DEBUG) -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7462) Do not log common CLI failures for Elytron to server log

by Ondrej Lukas (JIRA)

[ https://issues.jboss.org/browse/WFLY-7462?page=com.atlassian.jira.plugin.... ] Ondrej Lukas updated WFLY-7462: ------------------------------- Labels: user_experience (was: ) > Do not log common CLI failures for Elytron to server log > -------------------------------------------------------- > > Key: WFLY-7462 > URL: https://issues.jboss.org/browse/WFLY-7462 > Project: WildFly > Issue Type: Bug > Components: Security > Affects Versions: 11.0.0.Alpha1 > Reporter: Ondrej Lukas > Assignee: Darran Lofthouse > Priority: Critical > Labels: user_experience > > Almost every common CLI command failure from Elytron subsystem is logged as ERROR to server log. For example this means: > * trying to add duplicate resource -> ERROR in server log > * missing required attribute of any resource attribute in CLI command -> ERROR in server log > * missing capability -> ERROR in server log > * ... > Some reasons why these logs should not be logged to server log: > * Adding useless messages to server log. > * This is inconsistent with other subsystems (e.g. PicketBox). It can be confusing. > These common CLI command failures should be removed from the log, or logged on low level (i.e. DEBUG) -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ELY-690) NPE in elytron SPNEGO implementation in exceptional states

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/ELY-690?page=com.atlassian.jira.plugin.sy... ] Jan Kalina reopened ELY-690: ---------------------------- > NPE in elytron SPNEGO implementation in exceptional states > ---------------------------------------------------------- > > Key: ELY-690 > URL: https://issues.jboss.org/browse/ELY-690 > Project: WildFly Elytron > Issue Type: Bug > Components: Authentication Mechanisms > Reporter: Martin Choma > Assignee: Jan Kalina > Priority: Critical > > Http response code 500 + excpetion in server log: > {code} > 21:40:40,640 ERROR [io.undertow.request] (default task-2) UT005023: Exception handling request to /secured-webapp/secure/index.jsp: java.lang.NullPointerException > at org.wildfly.security.http.impl.SpnegoAuthenticationMechanism.authorizeEstablishedContext(SpnegoAuthenticationMechanism.java:177) > at org.wildfly.security.http.impl.SpnegoAuthenticationMechanism.evaluateRequest(SpnegoAuthenticationMechanism.java:128) > at org.wildfly.security.http.util.SetMechanismInformationMechanismFactory$1.evaluateRequest(SetMechanismInformationMechanismFactory.java:115) > at org.wildfly.security.http.util.SecurityIdentityServerMechanismFactory$1.evaluateRequest(SecurityIdentityServerMechanismFactory.java:77) > at org.wildfly.security.http.HttpAuthenticator$AuthenticationExchange.authenticate(HttpAuthenticator.java:106) > at org.wildfly.security.http.HttpAuthenticator$AuthenticationExchange.access$100(HttpAuthenticator.java:90) > at org.wildfly.security.http.HttpAuthenticator.authenticate(HttpAuthenticator.java:74) > at org.wildfly.elytron.web.undertow.server.SecurityContextImpl.authenticate(SecurityContextImpl.java:82) > at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:55) > at io.undertow.server.handlers.DisableCacheHandler.handleRequest(DisableCacheHandler.java:33) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:53) > at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46) > at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64) > at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:59) > at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292) > at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81) > at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138) > at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135) > at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48) > at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671) > at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272) > at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81) > at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104) > at io.undertow.server.Connectors.executeRootHandler(Connectors.java:207) > at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:810) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:745) > {code} > I have hit this in two situations so far > * accessing with kerberos ticket from another realm. E.g. application server is set for realm JBOSS.ORG, but client is jduke(a)REDHAT.COM > ** For this situation is http response code 500 disputable, as it could be viewed as problem of client. Client can change ticket and authentication can be performed just fine. > * misconfiguration e.g. wrong kdc in krb5.conf > Provide some meaningful error message. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ELY-712) Elytron GSSCredential propagation

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/ELY-712?page=com.atlassian.jira.plugin.sy... ] Jan Kalina edited comment on ELY-712 at 11/3/16 8:47 AM: --------------------------------------------------------- [~mchoma] has said, that [~dlofthouse] has said, that this will require https://github.com/wildfly-security/wildfly-elytron/pull/434 [ELY-473] which is not merged yet. Looks like it is really needed for this.... was (Author: honza889): [~mchoma] has said, that [~dlofthouse] has said, that this will require https://github.com/wildfly-security/wildfly-elytron/pull/434 which is not merged yet. > Elytron GSSCredential propagation > --------------------------------- > > Key: ELY-712 > URL: https://issues.jboss.org/browse/ELY-712 > Project: WildFly Elytron > Issue Type: Bug > Components: Authentication Mechanisms > Reporter: Jan Kalina > Assignee: Jan Kalina > > User can't achieve identity propagation scenario with elytron, so far: > # Client authenticate to web application using SPNEGO > # Web application calls another service (database, another web application, ... ) on behalf of user. > # Web applications wants to use provided gss credential, but there is no way to get associated credentials in elytron, so far > Basically use case tested in AS TS with legacy security [1] > Legacy approach using {{DelegationCredentialContext.getDelegCredential()}} return null in elytron. > Actually there exists pull request the delegated credential will be associated with the SecurityIdentity [2] . This JIRA is created mainly for tracking purpose to process it properly once pending commit gets to EAP. > [1] https://github.com/wildfly/wildfly/blob/15f9a4f2b5a10cc3acbaa2df57d5cc13d... testIdentityPropagation > [2] https://github.com/wildfly-security/wildfly-elytron/pull/434/commits/9b5a... -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7093) Transfer of contextData back to the jboss ejb client

by David Lloyd (JIRA)

[ https://issues.jboss.org/browse/WFLY-7093?page=com.atlassian.jira.plugin.... ] David Lloyd reassigned WFLY-7093: --------------------------------- Assignee: David Lloyd > Transfer of contextData back to the jboss ejb client > ---------------------------------------------------- > > Key: WFLY-7093 > URL: https://issues.jboss.org/browse/WFLY-7093 > Project: WildFly > Issue Type: Bug > Components: EJB > Affects Versions: 10.1.0.Final > Reporter: Teresa Miyar > Assignee: David Lloyd > Priority: Minor > > The spec says: > The getContextData method enables a business method, lifecycle callback method, or timeout method to retrieve any interceptor/webservices context associated with its invocation. > The way this context data travels from client to server is by copying the data into a server context, this data is used inside the server ejb but not copied back to client. Client requests that this contextData is populated from client to server and vice versa. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2123) Replace Tuple<Long, V> with LongTuple<V>

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-2123?page=com.atlassian.jira.plugin.... ] Bela Ban resolved JGRP-2123. ---------------------------- Resolution: Done > Replace Tuple<Long,V> with LongTuple<V> > --------------------------------------- > > Key: JGRP-2123 > URL: https://issues.jboss.org/browse/JGRP-2123 > Project: JGroups > Issue Type: Enhancement > Reporter: Bela Ban > Assignee: Bela Ban > Priority: Minor > Fix For: 4.0 > > > Tuples where keys are Long are used a lot. Oftentimes like this: > {code:java} > Tuple<Long,Message> tuple=...; > long id=...; > Message msg=tuple.get(id); > {code} > This results in a {{long}} getting boxed into a {{Long}}, each time allocating a new Long instance. > Todo: create a new LongTuple<V> class -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ELY-712) Elytron GSSCredential propagation

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/ELY-712?page=com.atlassian.jira.plugin.sy... ] Jan Kalina commented on ELY-712: -------------------------------- [~mchoma] has said, that [~dlofthouse] has said, that this will require https://github.com/wildfly-security/wildfly-elytron/pull/434 which is not merged yet. > Elytron GSSCredential propagation > --------------------------------- > > Key: ELY-712 > URL: https://issues.jboss.org/browse/ELY-712 > Project: WildFly Elytron > Issue Type: Bug > Components: Authentication Mechanisms > Reporter: Jan Kalina > Assignee: Jan Kalina > > User can't achieve identity propagation scenario with elytron, so far: > # Client authenticate to web application using SPNEGO > # Web application calls another service (database, another web application, ... ) on behalf of user. > # Web applications wants to use provided gss credential, but there is no way to get associated credentials in elytron, so far > Basically use case tested in AS TS with legacy security [1] > Legacy approach using {{DelegationCredentialContext.getDelegCredential()}} return null in elytron. > Actually there exists pull request the delegated credential will be associated with the SecurityIdentity [2] . This JIRA is created mainly for tracking purpose to process it properly once pending commit gets to EAP. > [1] https://github.com/wildfly/wildfly/blob/15f9a4f2b5a10cc3acbaa2df57d5cc13d... testIdentityPropagation > [2] https://github.com/wildfly-security/wildfly-elytron/pull/434/commits/9b5a... -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2123) Replace Tuple<Long, V> with LongTuple<V>

by Bela Ban (JIRA)

Bela Ban created JGRP-2123: ------------------------------ Summary: Replace Tuple<Long,V> with LongTuple<V> Key: JGRP-2123 URL: https://issues.jboss.org/browse/JGRP-2123 Project: JGroups Issue Type: Enhancement Reporter: Bela Ban Assignee: Bela Ban Priority: Minor Fix For: 4.0 Tuples where keys are Long are used a lot. Oftentimes like this: {code:java} Tuple<Long,Message> tuple=...; long id=...; Message msg=tuple.get(id); {code} This results in a {{long}} getting boxed into a {{Long}}, each time allocating a new Long instance. Todo: create a new LongTuple<V> class -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 8 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 November 2016