March 2017 - jboss-jira - Jboss List Archives

[JBoss JIRA] (SECURITY-921) SPNEGO authentication fails on Windows-KDC

by Radovan Netuka (JIRA)

[ https://issues.jboss.org/browse/SECURITY-921?page=com.atlassian.jira.plug... ] Radovan Netuka commented on SECURITY-921: ----------------------------------------- PR for 2.3.x: https://github.com/wildfly-security/jboss-negotiation/pull/35 > SPNEGO authentication fails on Windows-KDC > ------------------------------------------ > > Key: SECURITY-921 > URL: https://issues.jboss.org/browse/SECURITY-921 > Project: PicketBox > Issue Type: Bug > Components: Negotiation > Affects Versions: Negotiation_3_0_0_CR1, Negotiation_2_3_11_Final > Environment: * > Reporter: Harald Krause > Assignee: Radovan Netuka > Labels: web_security > > Inside the "SPNEGOLoginModule" (3.0.0.CR2-SNAPSHOT) the run()-Method of inner class "AcceptSecContext" checks for existence of Kerberos-oid within the SPNEGO-Token. But it checks solely the first element of the mechanism-list: > {code:java} > if (mechList.get(0).equals(kerberos)) > { > gssToken = negTokenInit.getMechToken(); > } > else > { > boolean kerberosSupported = false; > ... > {code} > But SPNEGO-Token from Windows-KDC (2008 R2) supports four types of authentication (oids): > * oid: 1.2.840.48018.1.2.2 (Windows Kerberos V5) > * oid: 1.2.840.113554.1.2.2 (Kerberos V5 - we are looking for) > * oid: 1.3.6.1.4.1.311.2.2.30 NegoEx > * oid: 1.3.6.1.4.1.311.2.2.10 NTLM > So Kerberos-check within run()-method should iterate the mechList until it founds Kerberos-V5-oid: > {code:java} > for (Oid oid : mechList) > { > if (oid.equals(kerberos)) > { > gssToken = negTokenInit.getMechToken(); > break; > } > } > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 4 months

1
0
0 / 0

[JBoss JIRA] (SECURITY-921) SPNEGO authentication fails on Windows-KDC

by Radovan Netuka (JIRA)

[ https://issues.jboss.org/browse/SECURITY-921?page=com.atlassian.jira.plug... ] Radovan Netuka updated SECURITY-921: ------------------------------------ Git Pull Request: https://github.com/wildfly-security/jboss-negotiation/pull/35 Affects Version/s: Negotiation_2_3_11_Final > SPNEGO authentication fails on Windows-KDC > ------------------------------------------ > > Key: SECURITY-921 > URL: https://issues.jboss.org/browse/SECURITY-921 > Project: PicketBox > Issue Type: Bug > Components: Negotiation > Affects Versions: Negotiation_3_0_0_CR1, Negotiation_2_3_11_Final > Environment: * > Reporter: Harald Krause > Assignee: Radovan Netuka > Labels: web_security > > Inside the "SPNEGOLoginModule" (3.0.0.CR2-SNAPSHOT) the run()-Method of inner class "AcceptSecContext" checks for existence of Kerberos-oid within the SPNEGO-Token. But it checks solely the first element of the mechanism-list: > {code:java} > if (mechList.get(0).equals(kerberos)) > { > gssToken = negTokenInit.getMechToken(); > } > else > { > boolean kerberosSupported = false; > ... > {code} > But SPNEGO-Token from Windows-KDC (2008 R2) supports four types of authentication (oids): > * oid: 1.2.840.48018.1.2.2 (Windows Kerberos V5) > * oid: 1.2.840.113554.1.2.2 (Kerberos V5 - we are looking for) > * oid: 1.3.6.1.4.1.311.2.2.30 NegoEx > * oid: 1.3.6.1.4.1.311.2.2.10 NTLM > So Kerberos-check within run()-method should iterate the mechList until it founds Kerberos-V5-oid: > {code:java} > for (Oid oid : mechList) > { > if (oid.equals(kerberos)) > { > gssToken = negTokenInit.getMechToken(); > break; > } > } > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 4 months

1
0
0 / 0

[JBoss JIRA] (SECURITY-921) SPNEGO authentication fails on Windows-KDC

by Radovan Netuka (JIRA)

[ https://issues.jboss.org/browse/SECURITY-921?page=com.atlassian.jira.plug... ] Radovan Netuka reassigned SECURITY-921: --------------------------------------- Assignee: Radovan Netuka (was: Darran Lofthouse) > SPNEGO authentication fails on Windows-KDC > ------------------------------------------ > > Key: SECURITY-921 > URL: https://issues.jboss.org/browse/SECURITY-921 > Project: PicketBox > Issue Type: Bug > Components: Negotiation > Affects Versions: Negotiation_3_0_0_CR1 > Environment: * > Reporter: Harald Krause > Assignee: Radovan Netuka > Labels: web_security > > Inside the "SPNEGOLoginModule" (3.0.0.CR2-SNAPSHOT) the run()-Method of inner class "AcceptSecContext" checks for existence of Kerberos-oid within the SPNEGO-Token. But it checks solely the first element of the mechanism-list: > {code:java} > if (mechList.get(0).equals(kerberos)) > { > gssToken = negTokenInit.getMechToken(); > } > else > { > boolean kerberosSupported = false; > ... > {code} > But SPNEGO-Token from Windows-KDC (2008 R2) supports four types of authentication (oids): > * oid: 1.2.840.48018.1.2.2 (Windows Kerberos V5) > * oid: 1.2.840.113554.1.2.2 (Kerberos V5 - we are looking for) > * oid: 1.3.6.1.4.1.311.2.2.30 NegoEx > * oid: 1.3.6.1.4.1.311.2.2.10 NTLM > So Kerberos-check within run()-method should iterate the mechList until it founds Kerberos-V5-oid: > {code:java} > for (Oid oid : mechList) > { > if (oid.equals(kerberos)) > { > gssToken = negTokenInit.getMechToken(); > break; > } > } > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-8288) Drop ASYNC cache mode, in favor of manual async operations and async commit/rollback

by Paul Ferraro (JIRA)

Paul Ferraro created WFLY-8288: ---------------------------------- Summary: Drop ASYNC cache mode, in favor of manual async operations and async commit/rollback Key: WFLY-8288 URL: https://issues.jboss.org/browse/WFLY-8288 Project: WildFly Issue Type: Enhancement Components: Clustering Reporter: Paul Ferraro Assignee: Paul Ferraro Infinispan is moving away from ASYNC mode, in favor of the async cache API. This is a good thing, as it clarifies cache operation semantics and eliminates the abuse of invocation flags. ASYNC vs SYNC behavior should move to the new subsystems for configuring web and ejb clustering profiles. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2359) Failure message when an op requires a non-existent capability doesn't list registration points for dynamic caps

by Brian Stansberry (JIRA)

Brian Stansberry created WFCORE-2359: ---------------------------------------- Summary: Failure message when an op requires a non-existent capability doesn't list registration points for dynamic caps Key: WFCORE-2359 URL: https://issues.jboss.org/browse/WFCORE-2359 Project: WildFly Core Issue Type: Bug Components: Domain Management Reporter: Brian Stansberry {code} [standalone@embedded /] /socket-binding-group=standard-sockets/socket-binding=test:add(interface=bogus,port=12345) { "outcome" => "failed", "failure-description" => "WFLYCTL0369: Required capabilities are not available: org.wildfly.network.interface.bogus; There are no known registration points which can provide this capability.", "rolled-back" => true } {code} The failure message is not fully helpful, since while there are no reg points for org.wildfly.network.interface.bogus there are points for caps whose dynamic part is org.wildfly.network.interface. The message is created using the results of CapabilityRegistry.getPossibleProviderPoints(), which just does a map lookup of the passed in capability name. Any fix that changes getPossibleProviderPoints() will need to be careful not to break other uses of that method. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6144) Global EJB Client Side Interceptors Configuration

by David Lloyd (JIRA)

[ https://issues.jboss.org/browse/WFLY-6144?page=com.atlassian.jira.plugin.... ] David Lloyd commented on WFLY-6144: ----------------------------------- All the jboss-ejb-client scaffolding is present now. Just needs management model changes to add the interceptors. > Global EJB Client Side Interceptors Configuration > ------------------------------------------------- > > Key: WFLY-6144 > URL: https://issues.jboss.org/browse/WFLY-6144 > Project: WildFly > Issue Type: Feature Request > Components: EJB > Reporter: Brad Maxwell > Assignee: David Lloyd > > Ability to configure global client side JBoss EJB interceptors and specify their order via the JBoss profile xml. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-8287) Elytron, log cause of LoginException during obraining ticket

by David Lloyd (JIRA)

David Lloyd created WFLY-8287: --------------------------------- Summary: Elytron, log cause of LoginException during obraining ticket Key: WFLY-8287 URL: https://issues.jboss.org/browse/WFLY-8287 Project: WildFly Issue Type: Bug Components: Security Reporter: Martin Choma Assignee: David Lloyd Priority: Critical I get to situation where in method {{GSSCredentialSecurityFactory.createGSSCredential()}} the cause of LoginException is hide from user. In log there is {code:title=server.log} 14:26:07,751 TRACE [org.wildfly.security] (default task-1) java.security.GeneralSecurityException: ELY01121: Unable to perform initial JAAS login. {code} But with debugger I get to obvious cause {{javax.security.auth.login.LoginException: Bad JAAS configuration: credsType and keytab values are not compatible}}, but this is not logged into log. Setting to high priority, because logging useful information is esential for troubleshooting fragile Kerberos setup. Mesage {code:java|title=ElytronMessages} @Message(id = 1121, value = "Unable to perform initial JAAS login.") GeneralSecurityException unableToPerformInitialLogin(@Cause LoginException cause); {code} is created in {code:java|title=GSSCredentialSecurityFactory.java#L283} } catch (LoginException e) { throw log.unableToPerformInitialLogin(e); } {code} and logged into log by {code:java|title=ServerAuthenticationContext.java#L847} } catch (GeneralSecurityException e) { // skip this credential log.trace(e); } {code} An more importantly. Question here is if some global issue should follow up? Because problem is in usage of log.trace(e) where although cause exception is avalaible, effectivelly is called log.trace(e.toString()) and cause is hidden; So probably some global check should be performed in elytron codebase if other such occurences aren't also problematic. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ELY-990) Elytron, log cause of LoginException during obraining ticket

by David Lloyd (JIRA)

[ https://issues.jboss.org/browse/ELY-990?page=com.atlassian.jira.plugin.sy... ] David Lloyd moved WFLY-8287 to ELY-990: --------------------------------------- Project: WildFly Elytron (was: WildFly) Key: ELY-990 (was: WFLY-8287) Component/s: Authentication Server (was: Security) > Elytron, log cause of LoginException during obraining ticket > ------------------------------------------------------------ > > Key: ELY-990 > URL: https://issues.jboss.org/browse/ELY-990 > Project: WildFly Elytron > Issue Type: Bug > Components: Authentication Server > Reporter: Martin Choma > Assignee: David Lloyd > Priority: Critical > > I get to situation where in method {{GSSCredentialSecurityFactory.createGSSCredential()}} the cause of LoginException is hide from user. > In log there is > {code:title=server.log} > 14:26:07,751 TRACE [org.wildfly.security] (default task-1) java.security.GeneralSecurityException: ELY01121: Unable to perform initial JAAS login. > {code} > But with debugger I get to obvious cause {{javax.security.auth.login.LoginException: Bad JAAS configuration: credsType and keytab values are not compatible}}, but this is not logged into log. > Setting to high priority, because logging useful information is esential for troubleshooting fragile Kerberos setup. > Mesage > {code:java|title=ElytronMessages} > @Message(id = 1121, value = "Unable to perform initial JAAS login.") > GeneralSecurityException unableToPerformInitialLogin(@Cause LoginException cause); > {code} > is created in > {code:java|title=GSSCredentialSecurityFactory.java#L283} > } catch (LoginException e) { > throw log.unableToPerformInitialLogin(e); > } > {code} > and logged into log by > {code:java|title=ServerAuthenticationContext.java#L847} > } catch (GeneralSecurityException e) { > // skip this credential > log.trace(e); > } > {code} > An more importantly. Question here is if some global issue should follow up? Because problem is in usage of log.trace(e) where although cause exception is avalaible, effectivelly is called log.trace(e.toString()) and cause is hidden; So probably some global check should be performed in elytron codebase if other such occurences aren't also problematic. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 4 months

1
0
0 / 0

[JBoss JIRA] (HAWKULARQE-56) Middleware Manager: Rolling upgrades (on Kubernetes)

by Hayk Hovsepyan (JIRA)

Hayk Hovsepyan created HAWKULARQE-56: ---------------------------------------- Summary: Middleware Manager: Rolling upgrades (on Kubernetes) Key: HAWKULARQE-56 URL: https://issues.jboss.org/browse/HAWKULARQE-56 Project: Hawkular QE Issue Type: Task Reporter: Hayk Hovsepyan Assignee: mfoley user Information from Heiko: This may be less of a need to Hawkular-Metrics in OS-Enterprise where people do some install from scratch, but I guess with the OS-Online 1st effort, we will deliver more releases in a quicker cadence, where the chance of such a rollback increases. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-8160) Webservice response File Descriptor leak

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/WFLY-8160?page=com.atlassian.jira.plugin.... ] Tomaz Cerar updated WFLY-8160: ------------------------------ Priority: Major (was: Blocker) > Webservice response File Descriptor leak > ---------------------------------------- > > Key: WFLY-8160 > URL: https://issues.jboss.org/browse/WFLY-8160 > Project: WildFly > Issue Type: Bug > Components: Web Services > Affects Versions: 9.0.0.Final, 9.0.2.Final, 10.1.0.Final > Environment: JDK: jdk1.8.0_121, jdk1.8.0_66 > WilfFly : wildfly-10.1.0.Final, wildfly-9.0.2.Final , wildfly-9.0.0.Final > OS: Red Hat Enterprise Linux Server release 7.1 (Maipo) > Hardware: 64 bit 4 core > Reporter: Mahesh Reddy > Assignee: Alessio Soldano > Attachments: BioMatcherWebserviceImpl.java, SOAP_REQUEST.txt, SOAP_RESPONSE.txt > > > We are getting File descriptor leak when wildfly responds to webservice call. > I think this happens if the webresvice response is huge complex structure, > I confirmed by adding the sleep just before the returning from the webservice method and checking lsof -p <pid>, And again checking it after client receives the response,. > I notice for each webservice call, 2 file descriptors are open and never closed. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 4 months

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 March 2017