April 2017 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-8552) Add support for GSSKerberosCredential in ElytronSubjectFactory

by Stefan Guilhen (JIRA)

Stefan Guilhen created WFLY-8552: ------------------------------------ Summary: Add support for GSSKerberosCredential in ElytronSubjectFactory Key: WFLY-8552 URL: https://issues.jboss.org/browse/WFLY-8552 Project: WildFly Issue Type: Task Components: JCA, Security Affects Versions: 11.0.0.Alpha1 Reporter: Stefan Guilhen Assignee: Stefano Maestri The JCA ElytronSubjectFactory must be improved to handle GSSKerberosCredentials to enable kerberos based authentication for databases. It should use a CredentialCallback of type GSSKerberosCredential to obtain the GSSCredential and associated KerberosTicket when building the Subject that is used to establish the connections to the DB. If the authentication configuration matched by the configured authentication context references a kerberos security factory, this factory will be used to create the credential and ticket that will in turn be inserted into the constructed Subject instance. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2655) Add option to wrap the GSSCredential in kerberos security factory

by Stefan Guilhen (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2655?page=com.atlassian.jira.plugi... ] Stefan Guilhen updated WFCORE-2655: ----------------------------------- Summary: Add option to wrap the GSSCredential in kerberos security factory (was: Add option to wrap the GSSCredential in the kerberos security factory) > Add option to wrap the GSSCredential in kerberos security factory > ----------------------------------------------------------------- > > Key: WFCORE-2655 > URL: https://issues.jboss.org/browse/WFCORE-2655 > Project: WildFly Core > Issue Type: Feature Request > Components: Security > Affects Versions: 3.0.0.Beta14 > Reporter: Stefan Guilhen > Assignee: Stefan Guilhen > Fix For: 3.0.0.Beta15 > > > The legacy KerberosLoginModule has an option called wrapGssCredential that tells the code building the GSSCredential that it should wrap the constructed credential to prevent improper credential disposal by some DB drivers. It essentially delegates every method to the wrapped GSSCredential but makes dispose() a no-op. > The kerberos security factory in Elytron doesn't offer an option to wrap the credential and it creates a backwards compatibility problem. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2654) Add support for kerberos security factory in authentication configuration

by Stefan Guilhen (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2654?page=com.atlassian.jira.plugi... ] Stefan Guilhen updated WFCORE-2654: ----------------------------------- Issue Type: Task (was: Feature Request) > Add support for kerberos security factory in authentication configuration > ------------------------------------------------------------------------- > > Key: WFCORE-2654 > URL: https://issues.jboss.org/browse/WFCORE-2654 > Project: WildFly Core > Issue Type: Task > Components: Security > Affects Versions: 3.0.0.Beta14 > Reporter: Stefan Guilhen > Assignee: Stefan Guilhen > Fix For: 3.0.0.Beta15 > > > The authentication-configuration section of the Elytron subsystem should allow for the specification of a kerberos-security-factory. This would allow client code to obtain the GSSCredential and associated KerberosTicket from the configuration using the CallbackHandler with a CredentialCallback of type GSSKerberosCredential. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ELY-1073) Add support for kerberos security factory in AuthenticationConfiguration

by Stefan Guilhen (JIRA)

[ https://issues.jboss.org/browse/ELY-1073?page=com.atlassian.jira.plugin.s... ] Stefan Guilhen updated ELY-1073: -------------------------------- Issue Type: Task (was: Feature Request) > Add support for kerberos security factory in AuthenticationConfiguration > ------------------------------------------------------------------------ > > Key: ELY-1073 > URL: https://issues.jboss.org/browse/ELY-1073 > Project: WildFly Elytron > Issue Type: Task > Reporter: Stefan Guilhen > Assignee: Stefan Guilhen > > Authentication configuration should be able to use a kerberos security factory to obtain the GSSCredential and associated KerberosTicket for authentication. The CallbackHandler code should check for CredentialCallbacks of type GSSKerberosCredential and use the configured factory to retrieve the credential and associated ticket. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2655) Add option to wrap the GSSCredential in the kerberos security factory

by Stefan Guilhen (JIRA)

Stefan Guilhen created WFCORE-2655: -------------------------------------- Summary: Add option to wrap the GSSCredential in the kerberos security factory Key: WFCORE-2655 URL: https://issues.jboss.org/browse/WFCORE-2655 Project: WildFly Core Issue Type: Feature Request Components: Security Affects Versions: 3.0.0.Beta14 Reporter: Stefan Guilhen Assignee: Stefan Guilhen Fix For: 3.0.0.Beta15 The legacy KerberosLoginModule has an option called wrapGssCredential that tells the code building the GSSCredential that it should wrap the constructed credential to prevent improper credential disposal by some DB drivers. It essentially delegates every method to the wrapped GSSCredential but makes dispose() a no-op. The kerberos security factory in Elytron doesn't offer an option to wrap the credential and it creates a backwards compatibility problem. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2654) Add support for kerberos security factory in authentication configuration

by Stefan Guilhen (JIRA)

Stefan Guilhen created WFCORE-2654: -------------------------------------- Summary: Add support for kerberos security factory in authentication configuration Key: WFCORE-2654 URL: https://issues.jboss.org/browse/WFCORE-2654 Project: WildFly Core Issue Type: Feature Request Components: Security Affects Versions: 3.0.0.Beta14 Reporter: Stefan Guilhen Assignee: Stefan Guilhen Fix For: 3.0.0.Beta15 The authentication-configuration section of the Elytron subsystem should allow for the specification of a kerberos-security-factory. This would allow client code to obtain the GSSCredential and associated KerberosTicket from the configuration using the CallbackHandler with a CredentialCallback of type GSSKerberosCredential. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ELY-1073) Add support for kerberos security factory in AuthenticationConfiguration

by Stefan Guilhen (JIRA)

Stefan Guilhen created ELY-1073: ----------------------------------- Summary: Add support for kerberos security factory in AuthenticationConfiguration Key: ELY-1073 URL: https://issues.jboss.org/browse/ELY-1073 Project: WildFly Elytron Issue Type: Feature Request Reporter: Stefan Guilhen Assignee: Stefan Guilhen Authentication configuration should be able to use a kerberos security factory to obtain the GSSCredential and associated KerberosTicket for authentication. The CallbackHandler code should check for CredentialCallbacks of type GSSKerberosCredential and use the configured factory to retrieve the credential and associated ticket. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2595) Get rid of the subsystem test framework's use of jboss-metadata-common

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2595?page=com.atlassian.jira.plugi... ] Brian Stansberry commented on WFCORE-2595: ------------------------------------------ [~dosoudil] FYI. I think it was a wildfly-core-eap PR from you that inspired me to get rid of this dependency in core so you guys wouldn't need to care about it. > Get rid of the subsystem test framework's use of jboss-metadata-common > ---------------------------------------------------------------------- > > Key: WFCORE-2595 > URL: https://issues.jboss.org/browse/WFCORE-2595 > Project: WildFly Core > Issue Type: Task > Components: Domain Management, Test Suite > Reporter: Brian Stansberry > Assignee: Brian Stansberry > Fix For: 3.0.0.Beta15 > > > The subsystem test framework's SchemaValidator class requires some expression resolution stuff from jboss-metadata-common, which means we have a test-only dep on that lib in core. Look into using something else for this, e.g. ExpressionResolver.SIMPLE_LENIENT. All it is doing is replacing expressions with defaults with the default value. > SchemaValidator is less useful than we originally envisioned anyway, as a lot of the subsystem templates cannot be valid as they include substitution data. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2595) Get rid of the subsystem test framework's use of jboss-metadata-common

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2595?page=com.atlassian.jira.plugi... ] Brian Stansberry reassigned WFCORE-2595: ---------------------------------------- Fix Version/s: 3.0.0.Beta15 Assignee: Brian Stansberry Resolution: Done > Get rid of the subsystem test framework's use of jboss-metadata-common > ---------------------------------------------------------------------- > > Key: WFCORE-2595 > URL: https://issues.jboss.org/browse/WFCORE-2595 > Project: WildFly Core > Issue Type: Task > Components: Domain Management, Test Suite > Reporter: Brian Stansberry > Assignee: Brian Stansberry > Fix For: 3.0.0.Beta15 > > > The subsystem test framework's SchemaValidator class requires some expression resolution stuff from jboss-metadata-common, which means we have a test-only dep on that lib in core. Look into using something else for this, e.g. ExpressionResolver.SIMPLE_LENIENT. All it is doing is replacing expressions with defaults with the default value. > SchemaValidator is less useful than we originally envisioned anyway, as a lot of the subsystem templates cannot be valid as they include substitution data. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2599) CLI complex object completer issues

by Jean-Francois Denise (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2599?page=com.atlassian.jira.plugi... ] Jean-Francois Denise updated WFCORE-2599: ----------------------------------------- Description: When a Complex Object property is ruled by filesystem or capability metadata, when the value to complete is already complete (full file name, full capability name), the completer miss behave. In this case, the completer doesn't propose the "," or "}" character that allows to continue Object completion. Another case of invalid completion for complex type: For example: /subsystem=logging/logger=xxx:add(filter={any={level=ALL}<TAB> The Parser will parse internally that onto: /subsystem=logging/logger=xxx:add(filter={any={level=ALL}*}* That makes the value-type completer to consider that the filter property is terminated and will propose content in a wrong context. By chance, tha tis not visible because it falls in a case where ',' is proposed. So the problem is hidden. It is visible with the computed visibility and deployment: /deployment=xxx:add(content=[{bytes=bytes{0x45}<TAB> ==> must propose /deployment=xxx:add(content=[{bytes=bytes{0x45}*}* was: When a Complex Object property is ruled by filesystem or capability metadata, when the value to complete is already complete (full file name, full capability name), the completer miss behave. In this case, the completer doesn't propose the "," or "}" character that allows to continue Object completion. > CLI complex object completer issues > ----------------------------------- > > Key: WFCORE-2599 > URL: https://issues.jboss.org/browse/WFCORE-2599 > Project: WildFly Core > Issue Type: Bug > Components: CLI > Reporter: Jean-Francois Denise > Assignee: Jean-Francois Denise > Priority: Minor > > When a Complex Object property is ruled by filesystem or capability metadata, when the value to complete is already complete (full file name, full capability name), the completer miss behave. > In this case, the completer doesn't propose the "," or "}" character that allows to continue Object completion. > Another case of invalid completion for complex type: > For example: > /subsystem=logging/logger=xxx:add(filter={any={level=ALL}<TAB> > The Parser will parse internally that onto: > /subsystem=logging/logger=xxx:add(filter={any={level=ALL}*}* > That makes the value-type completer to consider that the filter property is terminated and will propose content in a wrong context. By chance, tha tis not visible because it falls in a case where ',' is proposed. So the problem is hidden. > It is visible with the computed visibility and deployment: > /deployment=xxx:add(content=[{bytes=bytes{0x45}<TAB> ==> must propose /deployment=xxx:add(content=[{bytes=bytes{0x45}*}* -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 3 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 April 2017