April 2018 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFCORE-3321) The jboss.dist system property is not used in testsuite/elytron module

by Kabir Khan (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3321?page=com.atlassian.jira.plugi... ] Kabir Khan closed WFCORE-3321. ------------------------------ > The jboss.dist system property is not used in testsuite/elytron module > ---------------------------------------------------------------------- > > Key: WFCORE-3321 > URL: https://issues.jboss.org/browse/WFCORE-3321 > Project: WildFly Core > Issue Type: Bug > Components: Test Suite > Affects Versions: 3.0.3.Final > Reporter: Yeray Borges > Assignee: Yeray Borges > Priority: Critical > Fix For: 3.0.10.Final > > > Elytron testsuite module doesn't work correctly with the {{jboss.dist}} system property. > The {{jboss.dist}} system property is used by QE to run the AS testsuite against the correct bits (e.g. comming from PROD team). The {{testsuite/integration/elytron}} module seems not to be taking this property into account. It seems it always uses output of {{wildfly-server-provisioning-maven-plugin}} to test against. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2767) Elytron Keystore resource needs restart when is changed credential-reference attribute but restart-required is set to "no-services"

by Kabir Khan (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2767?page=com.atlassian.jira.plugi... ] Kabir Khan closed WFCORE-2767. ------------------------------ > Elytron Keystore resource needs restart when is changed credential-reference attribute but restart-required is set to "no-services" > ----------------------------------------------------------------------------------------------------------------------------------- > > Key: WFCORE-2767 > URL: https://issues.jboss.org/browse/WFCORE-2767 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Hynek Švábek > Assignee: Yeray Borges > Priority: Critical > > Elytron Keystore resource needs restart when is changed credential-reference attribute but restart-required is set to "no-services" > There should be rather restart-required set to "resource-services" and ability to use allow-resource-service-restart=true header property -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2527) There is wrong default *relative-to* path for CredentialStore, is set to folder from which we started EAP server.

by Kabir Khan (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2527?page=com.atlassian.jira.plugi... ] Kabir Khan closed WFCORE-2527. ------------------------------ > There is wrong default *relative-to* path for CredentialStore, is set to folder from which we started EAP server. > ----------------------------------------------------------------------------------------------------------------- > > Key: WFCORE-2527 > URL: https://issues.jboss.org/browse/WFCORE-2527 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Hynek Švábek > Assignee: Darran Lofthouse > Priority: Critical > > There is set wrong default *relative-to* path for CredentialStore. > Default *relative-to* path is set to folder from which we started EAP server. > e.g.: > * cd EAP_FOLDER > * ./bin/standalone.sh > * relative-to is se to EAP_FOLDER > or > * cd EAP_FODER/bin > * ./standalone.sh > * relative-to is se to EAP_FOLDER/bin > *How to reproduce* > {code} > /subsystem=elytron/credential-store=cs007:add(uri="cr-store://test/keystorecs007.jceks?create=true", credential-reference= {clear-text=pass123}) > {code} > {code} > /subsystem=elytron/credential-store=cs007/alias=newCs007:add(secret-value=Elytron) > {code} > Now you can see in EAP_FOLDER (it can be different, see above) keystorecs007.jceks file. > I would expect this file in data directory of server. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2503) Legacy security domain used as Elytron security realm does not work in authorization part of aggregate-realm

by Kabir Khan (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2503?page=com.atlassian.jira.plugi... ] Kabir Khan closed WFCORE-2503. ------------------------------ > Legacy security domain used as Elytron security realm does not work in authorization part of aggregate-realm > ------------------------------------------------------------------------------------------------------------ > > Key: WFCORE-2503 > URL: https://issues.jboss.org/browse/WFCORE-2503 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Ondrej Lukas > Assignee: Darran Lofthouse > Priority: Critical > Attachments: print-roles.war > > > In case when legacy security domain is used as Elytron security realm and is added as authorization realm to aggregate-realm then no roles are assigned to authenticated user. > I tried to use following legacy security domain: > {code} > <security-domain name="legacyDomain" cache-type="default"> > <authentication> > <login-module code="UsersRoles" flag="required"> > <module-option name="usersProperties" value="/tmp/users.properties"/> > <module-option name="rolesProperties" value="/tmp/roles.properties"/> > </login-module> > </authentication> > <mapping> > <mapping-module code="SimpleRoles" type="role"> > <module-option name="admin" value="User"/> > </mapping-module> > </mapping> > </security-domain> > {code} > Roles should be assigned from mapping. Since it seems that there is no documentation related to this topic I am not sure whether roles should be assigned also from rolesProperties of UsersRoles login module - it needs to be clarified by developers. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2490) Multiple CredentialStores with ONE backed credential store file can rewrite values each other.

by Kabir Khan (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2490?page=com.atlassian.jira.plugi... ] Kabir Khan closed WFCORE-2490. ------------------------------ > Multiple CredentialStores with ONE backed credential store file can rewrite values each other. > ---------------------------------------------------------------------------------------------- > > Key: WFCORE-2490 > URL: https://issues.jboss.org/browse/WFCORE-2490 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Hynek Švábek > Assignee: Peter Skopek > Priority: Blocker > > Multiple CredentialStores with ONE backed credential store file can rewrite values each other. > *How to reproduce* > {code} > /subsystem=elytron/credential-store=credStore001:add(uri="cr-store://test/cs001.jceks?store.password=pass123;create.storage=true") > /subsystem=elytron/credential-store=credStore001/alias="alias1":add(secret-value=Elytron) > {code} > {code} > /subsystem=elytron/credential-store=credStore002:add(uri="cr-store://test/cs001.jceks?store.password=pass123") > {code} > check CS file > there is "alias1" entry > {code} > /subsystem=elytron/credential-store=credStore001/alias="alias2":add(secret-value=Elytron) > {code} > check CS file > there are "alias1" and "alias2" entries > {code} > /subsystem=elytron/credential-store=credStore002/alias="alias123":add(secret-value=Elytron) > {code} > check CS file > there are "alias1" and "alias123" entries". > *NOTE* > It is problem, because we have one backed file. In memory we have right values for all Credential Stores, but after restart we can lost new entries. > In my opinion reason for this behaviour is: > We have CS loaded in memory and when we add new alias to CS then we save whole CS from memory to file. > We can set CS as non-modifiable when we use same backed file for CredentialStore but we must find better default behaviour. > *My suggestion for default behaviour* > When we want to add new alias to CredentialStore we can do this: > # refresh CS from file (and this file lock) > # add new alias to CS > # save CS to file > # unlock file > *But there is posible problem with performance....* -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2485) CS tool, add prompt when --password is missing

by Kabir Khan (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2485?page=com.atlassian.jira.plugi... ] Kabir Khan closed WFCORE-2485. ------------------------------ > CS tool, add prompt when --password is missing > ---------------------------------------------- > > Key: WFCORE-2485 > URL: https://issues.jboss.org/browse/WFCORE-2485 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Martin Choma > Assignee: Darran Lofthouse > Priority: Blocker > Labels: credential-store > > Use case: > - User have automation script using cs tool and user don't want to have password stored in file. > - User don't want credential store password to be stored in shell history after execution. > - User don't want credential store password to be listed in {{ps -aux}} output. > There have to be possibility to omit --password attribute. When omitting --password attribute user interaction prompt should follow with possibility to input password. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2444) There isn't possibility log in to management web console as user which was dynamically added after EAP was started.

by Kabir Khan (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2444?page=com.atlassian.jira.plugi... ] Kabir Khan closed WFCORE-2444. ------------------------------ > There isn't possibility log in to management web console as user which was dynamically added after EAP was started. > ------------------------------------------------------------------------------------------------------------------- > > Key: WFCORE-2444 > URL: https://issues.jboss.org/browse/WFCORE-2444 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Hynek Švábek > Assignee: Darran Lofthouse > Priority: Critical > > I am not able to log in to management web console as user which was dynamically added after EAP was started. > *Scenario:* > * EAP is running - *standalone.sh -c=standalone-elytron.xml* > * add user through script *add-user.sh -u john -p password1! -s* > * log in to management web console as user *john* > *Result:* > * It doesn't work until restart > When we use Picketbox then it works fine. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2420) JMS client dependencies doesn't contain a default wildfly-config.xml

by Kabir Khan (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2420?page=com.atlassian.jira.plugi... ] Kabir Khan closed WFCORE-2420. ------------------------------ > JMS client dependencies doesn't contain a default wildfly-config.xml > -------------------------------------------------------------------- > > Key: WFCORE-2420 > URL: https://issues.jboss.org/browse/WFCORE-2420 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Josef Cacek > Assignee: Jeff Mesnil > Priority: Critical > > Using the {{wildfly-jms-client-bom}} dependency for JMS clients doesn't introduce a default {{wildfly-config.xml}} with Elytron client configuration. As the result, clients are not able to authenticate (e.g. using JBOSS-LOCAL-USER SASL mechanism). > The default configuration in {{wildfly-config.xml}} should allow similar behavior as with legacy security. So the following call should pass: > {code} > ConnectionFactory connectionFactory = (ConnectionFactory) namingContext.lookup("jms/RemoteConnectionFactory"); > {code} > Currently the call throws exception: > {code} > SEVERE: Naming problem occured > javax.naming.CommunicationException: WFNAM00018: Failed to connect to remote host [Root exception is javax.security.sasl.SaslException: Authentication failed: none of the mechanisms presented by the server are supported] > at org.wildfly.naming.client.remote.RemoteNamingProvider.getPeerIdentityForNaming(RemoteNamingProvider.java:110) > at org.wildfly.naming.client.remote.RemoteContext.lookupNative(RemoteContext.java:91) > at org.wildfly.naming.client.AbstractFederatingContext.lookup(AbstractFederatingContext.java:78) > at org.wildfly.naming.client.AbstractFederatingContext.lookup(AbstractFederatingContext.java:64) > at org.wildfly.naming.client.WildFlyRootContext.lookup(WildFlyRootContext.java:123) > at org.wildfly.naming.client.WildFlyRootContext.lookup(WildFlyRootContext.java:113) > at javax.naming.InitialContext.lookup(InitialContext.java:417) > at org.wildfly.security.elytron.demo.JmsClient.main(JmsClient.java:45) > Caused by: javax.security.sasl.SaslException: Authentication failed: none of the mechanisms presented by the server are supported > at org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities.handleEvent(ClientConnectionOpenListener.java:412) > at org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities.handleEvent(ClientConnectionOpenListener.java:239) > at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) > at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66) > at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:89) > at org.xnio.nio.WorkerThread.run(WorkerThread.java:567) > at ...asynchronous invocation...(Unknown Source) > at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:466) > at org.jboss.remoting3.FutureConnection.connect(FutureConnection.java:113) > at org.jboss.remoting3.FutureConnection.init(FutureConnection.java:75) > at org.jboss.remoting3.FutureConnection.get(FutureConnection.java:151) > at org.jboss.remoting3.EndpointImpl.getConnection(EndpointImpl.java:422) > at org.jboss.remoting3.UncloseableEndpoint.getConnection(UncloseableEndpoint.java:57) > at org.jboss.remoting3.Endpoint.getConnection(Endpoint.java:105) > at org.wildfly.naming.client.remote.RemoteNamingProvider.lambda$new$0(RemoteNamingProvider.java:68) > at org.wildfly.naming.client.remote.RemoteNamingProvider.getPeerIdentity(RemoteNamingProvider.java:126) > at org.wildfly.naming.client.remote.RemoteNamingProvider.getPeerIdentityForNaming(RemoteNamingProvider.java:108) > ... 7 more > {code} -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2412) Complex type key-store in Elytron subsystem

by Kabir Khan (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2412?page=com.atlassian.jira.plugi... ] Kabir Khan closed WFCORE-2412. ------------------------------ > Complex type key-store in Elytron subsystem > ------------------------------------------- > > Key: WFCORE-2412 > URL: https://issues.jboss.org/browse/WFCORE-2412 > Project: WildFly Core > Issue Type: Bug > Components: Security > Affects Versions: 3.0.0.Beta7 > Reporter: Ondrej Lukas > Assignee: Darran Lofthouse > Priority: Critical > > Elytron subsystem uses complex type in key-store resource which is difficult to use and can result to bad user experience, see description of JBEAP-6100 for more details. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2419) Complex type simple-permission-mapper in Elytron subsystem

by Kabir Khan (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2419?page=com.atlassian.jira.plugi... ] Kabir Khan closed WFCORE-2419. ------------------------------ > Complex type simple-permission-mapper in Elytron subsystem > ---------------------------------------------------------- > > Key: WFCORE-2419 > URL: https://issues.jboss.org/browse/WFCORE-2419 > Project: WildFly Core > Issue Type: Bug > Components: Security > Affects Versions: 3.0.0.Beta7 > Reporter: Ondrej Lukas > Assignee: Darran Lofthouse > Priority: Critical > > Elytron subsystem uses complex type in simple-permission-mapper resource which is difficult to use and can result to bad user experience, see description of JBEAP-6100 for more details. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 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 April 2018