May 2018 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-10242) Unify secmgr JAVA_OPTS behaviour in WF scripts

by David Lloyd (JIRA)

[ https://issues.jboss.org/browse/WFLY-10242?page=com.atlassian.jira.plugin... ] David Lloyd commented on WFLY-10242: ------------------------------------ There is no circumstance, past or present, where {{-secmgr}} was allowed, added, or supported in {{JAVA_OPTS}}. The old way to run with a security manager, before (I believe) WF 10, was to pass the system property {{java.security.manager}} in to the JVM's arguments. After WF 10, the way to do it was to pass {{-secmgr}} into the startup script, which in turn put {{-segmgr}} into the argument list of JBoss Modules (_not_ the JVM itself) causing our own security manager to be enabled. > Unify secmgr JAVA_OPTS behaviour in WF scripts > ---------------------------------------------- > > Key: WFLY-10242 > URL: https://issues.jboss.org/browse/WFLY-10242 > Project: WildFly > Issue Type: Bug > Components: Scripts > Reporter: Marek Kopecký > Assignee: Kabir Khan > > Unify secmgr JAVA_OPTS behaviour in WF scripts. > standalone&&domain&&appclient scripts doesn't allow to use secmgr by JAVA_OPTS definition. wsconsume&&wsprovide scripts allow that (see [this|https://github.com/wildfly/wildfly/blob/master/feature-pack/src/main...] and [this|https://github.com/wildfly/wildfly/blob/master/feature-pack/src/main...]) > All scripts should be unified. > cc: [~asoldano], [~jamezp], [~jbliznak], [~msvehla] -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-10242) Unify secmgr JAVA_OPTS behaviour in WF scripts

by R Searls (JIRA)

[ https://issues.jboss.org/browse/WFLY-10242?page=com.atlassian.jira.plugin... ] R Searls commented on WFLY-10242: --------------------------------- I would like to understand the history of -secmgr. I've looked through prior versions of wfly. I see that no mention of -Djava.security.manager or -secmgr is made in the scripts until version 10.0.0.Final. It is in this version that JAVA_OPTS is checked for these options. In versions prior to 10.0.0.Final were users required to make a conscious decision to specify -Djava.security.manager to get the behavior they wanted? Was there wfly user documentation describing declaring this in JAVA_OPTS? Is there wfly user documentation describing the switch from -Djava.security.manager to -secmgr usage? Is setting -secmgr in JAVA_OPTS an effort to maintain backward compatibility (e.g. -Djava.security.manager was set there; -secmgr is replacing it so should be set there as well)? > Unify secmgr JAVA_OPTS behaviour in WF scripts > ---------------------------------------------- > > Key: WFLY-10242 > URL: https://issues.jboss.org/browse/WFLY-10242 > Project: WildFly > Issue Type: Bug > Components: Scripts > Reporter: Marek Kopecký > Assignee: Kabir Khan > > Unify secmgr JAVA_OPTS behaviour in WF scripts. > standalone&&domain&&appclient scripts doesn't allow to use secmgr by JAVA_OPTS definition. wsconsume&&wsprovide scripts allow that (see [this|https://github.com/wildfly/wildfly/blob/master/feature-pack/src/main...] and [this|https://github.com/wildfly/wildfly/blob/master/feature-pack/src/main...]) > All scripts should be unified. > cc: [~asoldano], [~jamezp], [~jbliznak], [~msvehla] -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ELY-1582) [GSS](7.1.z) Support hex encoding in jdbc-realm for elytron

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/ELY-1582?page=com.atlassian.jira.plugin.s... ] Jan Kalina moved WFCORE-3840 to ELY-1582: ----------------------------------------- Project: WildFly Elytron (was: WildFly Core) Key: ELY-1582 (was: WFCORE-3840) Component/s: Realms (was: Security) Affects Version/s: 1.3.2.Final (was: 5.0.0.Alpha7) > [GSS](7.1.z) Support hex encoding in jdbc-realm for elytron > ----------------------------------------------------------- > > Key: ELY-1582 > URL: https://issues.jboss.org/browse/ELY-1582 > Project: WildFly Elytron > Issue Type: Feature Request > Components: Realms > Affects Versions: 1.3.2.Final > Reporter: Jan Kalina > Assignee: Jan Kalina > Labels: elytron > > Old database login-module can be configured passing the attribute {{hashEncoding}}, for example: > {code:xml} > <login-module code="Database" flag="required"> > <module-option name="dsJndiName" value="java:jboss/datasources/ExampleDS"/> > <module-option name="principalsQuery" value="SELECT password FROM User WHERE username = ?"/> > <module-option name="rolesQuery" value="SELECT role, 'Roles' FROM User WHERE username = ?"/> > <module-option name="hashAlgorithm" value="SHA-1"/> > <module-option name="hashEncoding" value="hex"/> > <module-option name="hashCharset" value="UTF-8"/> > </login-module> > {code} > Currently jdbc-realm in elytron only uses base64 encoding if hash is stored in a text column. This way the migration is more complicated cos the password hash is not valid changing from old security system to elytron. > Think also about the charset attribute. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3840) [GSS](7.1.z) Support hex encoding in jdbc-realm for elytron

by Jan Kalina (JIRA)

Jan Kalina created WFCORE-3840: ---------------------------------- Summary: [GSS](7.1.z) Support hex encoding in jdbc-realm for elytron Key: WFCORE-3840 URL: https://issues.jboss.org/browse/WFCORE-3840 Project: WildFly Core Issue Type: Feature Request Components: Security Affects Versions: 5.0.0.Alpha7 Reporter: Jan Kalina Assignee: Jan Kalina Old database login-module can be configured passing the attribute {{hashEncoding}}, for example: {code:xml} <login-module code="Database" flag="required"> <module-option name="dsJndiName" value="java:jboss/datasources/ExampleDS"/> <module-option name="principalsQuery" value="SELECT password FROM User WHERE username = ?"/> <module-option name="rolesQuery" value="SELECT role, 'Roles' FROM User WHERE username = ?"/> <module-option name="hashAlgorithm" value="SHA-1"/> <module-option name="hashEncoding" value="hex"/> <module-option name="hashCharset" value="UTF-8"/> </login-module> {code} Currently jdbc-realm in elytron only uses base64 encoding if hash is stored in a text column. This way the migration is more complicated cos the password hash is not valid changing from old security system to elytron. Think also about the charset attribute. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3839) Cannot read-identity of filesystem-realm if change level attribute later

by Claudio Miranda (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3839?page=com.atlassian.jira.plugi... ] Claudio Miranda updated WFCORE-3839: ------------------------------------ Description: Add filesystem-realm, add a identity, then change the levels to 3, the previously added identity cannot be recovered anymore. This is due to the directory structure previously created. Perhaps, the levels attribute should be set at creation time only ? {code} [standalone@localhost:9990 /] /subsystem=elytron/filesystem-realm=file_realm1:add(path=file_realm) {"outcome" => "success"} [standalone@localhost:9990 /] /subsystem=elytron/filesystem-realm=file_realm1:add-identity(identity=user1) {"outcome" => "success"} [standalone@localhost:9990 /] /subsystem=elytron/filesystem-realm=file_realm1:read-identity(identity=user1) { "outcome" => "success", "result" => { "name" => "user1", "attributes" => undefined } } [standalone@localhost:9990 /] /subsystem=elytron/filesystem-realm=file_realm1:write-attribute(name=levels,value=3) { "outcome" => "success", "response-headers" => { "operation-requires-reload" => true, "process-state" => "reload-required" } } [standalone@localhost:9990 /] reload [standalone@localhost:9990 /] /subsystem=elytron/filesystem-realm=file_realm1:read-identity(identity=user1) { "outcome" => "failed", "failure-description" => "WFLYELY01002: Identity with name [user1] not found.", "rolled-back" => true } {code} was:Add filesystem-realm, add a identity, then change the levels to 3, the previously added identity cannot be recovered anymore. This is due to the directory structure previously created. > Cannot read-identity of filesystem-realm if change level attribute later > ------------------------------------------------------------------------ > > Key: WFCORE-3839 > URL: https://issues.jboss.org/browse/WFCORE-3839 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Claudio Miranda > Assignee: Darran Lofthouse > > Add filesystem-realm, add a identity, then change the levels to 3, the previously added identity cannot be recovered anymore. This is due to the directory structure previously created. Perhaps, the levels attribute should be set at creation time only ? > {code} > [standalone@localhost:9990 /] /subsystem=elytron/filesystem-realm=file_realm1:add(path=file_realm) > {"outcome" => "success"} > [standalone@localhost:9990 /] /subsystem=elytron/filesystem-realm=file_realm1:add-identity(identity=user1) > {"outcome" => "success"} > [standalone@localhost:9990 /] /subsystem=elytron/filesystem-realm=file_realm1:read-identity(identity=user1) > { > "outcome" => "success", > "result" => { > "name" => "user1", > "attributes" => undefined > } > } > [standalone@localhost:9990 /] /subsystem=elytron/filesystem-realm=file_realm1:write-attribute(name=levels,value=3) > { > "outcome" => "success", > "response-headers" => { > "operation-requires-reload" => true, > "process-state" => "reload-required" > } > } > [standalone@localhost:9990 /] reload > [standalone@localhost:9990 /] /subsystem=elytron/filesystem-realm=file_realm1:read-identity(identity=user1) > { > "outcome" => "failed", > "failure-description" => "WFLYELY01002: Identity with name [user1] not found.", > "rolled-back" => true > } > {code} -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3839) Cannot read-identity of filesystem-realm if change level attribute later

by Claudio Miranda (JIRA)

Claudio Miranda created WFCORE-3839: --------------------------------------- Summary: Cannot read-identity of filesystem-realm if change level attribute later Key: WFCORE-3839 URL: https://issues.jboss.org/browse/WFCORE-3839 Project: WildFly Core Issue Type: Bug Components: Security Reporter: Claudio Miranda Assignee: Darran Lofthouse Add filesystem-realm, add a identity, then change the levels to 3, the previously added identity cannot be recovered anymore. This is due to the directory structure previously created. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ELY-1239) Elytron client, elytron-1_0.xsd, protection-parameter-credentials is incorrectly defined as client-credentials-type.

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-1239?page=com.atlassian.jira.plugin.s... ] Darran Lofthouse updated ELY-1239: ---------------------------------- Fix Version/s: 1.3.3.CR1 (was: 1.3.2.Final) > Elytron client, elytron-1_0.xsd, protection-parameter-credentials is incorrectly defined as client-credentials-type. > -------------------------------------------------------------------------------------------------------------------- > > Key: ELY-1239 > URL: https://issues.jboss.org/browse/ELY-1239 > Project: WildFly Elytron > Issue Type: Bug > Components: Authentication Client, Credential Store > Reporter: Hynek Švábek > Assignee: Peter Skopek > Priority: Blocker > Fix For: 1.3.3.CR1 > > > Elytron client, elytron-1_0.xsd, *protection-parameter-credentials* is incorrectly defined as client-credentials-type [1]. > For *protection-parameter-credentials* is valid only credential-store-reference element: > {code} > <xsd:element name="credential-store-reference" type="credential-store-reference-type"/> > {code} > But now is *protection-parameter-credentials* defined as type *client-credentials-type* [1] which can have these values: > {code} > <xsd:complexType name="client-credentials-type"> > <xsd:choice minOccurs="0" maxOccurs="unbounded"> > <xsd:element name="key-store-reference" type="key-store-ref-type"/> > <xsd:element name="credential-store-reference" type="credential-store-reference-type"/> > <xsd:element name="clear-password" type="clear-password-type"/> > <xsd:element name="hashed-password" type="hashed-password-type"/> > <xsd:element name="crypt-password" type="crypt-password-type"/> > <xsd:element name="key-pair" type="key-pair-type"/> > <xsd:element name="certificate" type="certificate-type"/> > <xsd:element name="public-key-pem" type="xsd:string"/> > <xsd:element name="bearer-token" type="bearer-token-type"/> > <xsd:element name="oauth2-bearer-token" type="oauth2-bearer-token-type"/> > </xsd:choice> > </xsd:complexType> > {code} > Please keep on mind that changes must be done accordingly in ElytronXMLParser too. > [1] https://github.com/wildfly-security/wildfly-elytron/blob/1.1.0.Beta47/src... -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ELY-816) Support for masked passwords in client XML config

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-816?page=com.atlassian.jira.plugin.sy... ] Darran Lofthouse updated ELY-816: --------------------------------- Fix Version/s: 1.3.3.CR1 (was: 1.3.2.Final) > Support for masked passwords in client XML config > ------------------------------------------------- > > Key: ELY-816 > URL: https://issues.jboss.org/browse/ELY-816 > Project: WildFly Elytron > Issue Type: Task > Reporter: David Lloyd > Assignee: Jan Kalina > Priority: Critical > Fix For: 1.3.3.CR1 > > > We need a way to support masked passwords in the auth configuration file, either as: > * A dedicated masked-password-type XML type > * Adding necessary fields to hashed-password-type > * Adding a modular crypt format > Needs to be supported anywhere passwords are allowed. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ELY-787) SASL mechanisms are not IANA registered and specifications are not provided

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-787?page=com.atlassian.jira.plugin.sy... ] Darran Lofthouse updated ELY-787: --------------------------------- Fix Version/s: 1.3.3.CR1 (was: 1.3.2.Final) > SASL mechanisms are not IANA registered and specifications are not provided > --------------------------------------------------------------------------- > > Key: ELY-787 > URL: https://issues.jboss.org/browse/ELY-787 > Project: WildFly Elytron > Issue Type: Task > Reporter: Josef Cacek > Priority: Critical > Labels: sasl > Fix For: 1.3.3.CR1 > > > Elytron comes with set of SASL mechanisms (as requested by EAP7-530), but they don't fit SASL requirements. > New mechanisms has to be registered by IANA as requested by [SASL RFC 4422 section 5|https://tools.ietf.org/html/rfc4422#section-5] and Java [SaslClientFactory|http://docs.oracle.com/javase/8/docs/api/javax/security...] and [SaslServerFactory|http://docs.oracle.com/javase/8/docs/api/javax/security...] contracts. > Current list of mechanisms provided by Elytron, which are not IANA registered: > * DIGEST-SHA > * DIGEST-SHA-256 > * DIGEST-SHA-512 > * JBOSS-LOCAL-USER > *Suggestion for improvement:* > Provide specifications for the new mechanisms and register the names by IANA (see [section 7 in RFC-4422|https://tools.ietf.org/html/rfc4422#section-7]). -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ELY-533) Deprecate all legacy code

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-533?page=com.atlassian.jira.plugin.sy... ] Darran Lofthouse updated ELY-533: --------------------------------- Fix Version/s: 1.3.3.CR1 (was: 1.3.2.Final) > Deprecate all legacy code > ------------------------- > > Key: ELY-533 > URL: https://issues.jboss.org/browse/ELY-533 > Project: WildFly Elytron > Issue Type: Task > Components: API / SPI > Reporter: Darran Lofthouse > Priority: Critical > Fix For: 1.3.3.CR1 > > > In a few places we have legacy behaviour within the project to assist migration from previous JBoss / WildFly releases - this code should be flagged as deprecated to encourage minimal use. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 2 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 May 2018