September 2015 - jboss-jira - Jboss List Archives

[JBoss JIRA] (ELY-154) Session based DigestCredential support

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-154?page=com.atlassian.jira.plugin.sy... ] Darran Lofthouse updated ELY-154: --------------------------------- Fix Version/s: 1.1.0.Alpha2 (was: 1.1.0.Alpha1) > Session based DigestCredential support > -------------------------------------- > > Key: ELY-154 > URL: https://issues.jboss.org/browse/ELY-154 > Project: WildFly Elytron > Issue Type: Sub-task > Components: Passwords > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 1.1.0.Alpha2 > > > DigestCredential but where additional information is included such as nonce and cnonce to create a credential applicable to a session. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ELY-299) Add getCredentialSupport methods that taks the credential type as an argument.

by Darran Lofthouse (JIRA)

Darran Lofthouse created ELY-299: ------------------------------------ Summary: Add getCredentialSupport methods that taks the credential type as an argument. Key: ELY-299 URL: https://issues.jboss.org/browse/ELY-299 Project: WildFly Elytron Issue Type: Enhancement Components: API / SPI Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 1.1.0.Alpha1 In ELY-282 getCredentialSupport is being switched to check based on credential name, however at the mechanism level there is still a need to know that the correct type can also be obtained as a mechanism is also dependent on the type. If we add getCredentialSupport(String credentialName, Class<?> credentialType) we can convert the methods that just take credential name to be default methods that call getCredentialSupport(credentialName, Object.class); -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5179) Some tests are unable to init arquillian protocol with security manager

by Gytis Trikleris (JIRA)

[ https://issues.jboss.org/browse/WFLY-5179?page=com.atlassian.jira.plugin.... ] Gytis Trikleris commented on WFLY-5179: --------------------------------------- Just to let you know, I'm updating RTS and XTS tests to work with security manager: https://github.com/gytis/jboss-as/commit/6799626bff25cd40fe1f0a68e94b72c1... I have to push changed to the Narayana code base first. But after that, I'll push test changes to WildFly upstream too. > Some tests are unable to init arquillian protocol with security manager > ----------------------------------------------------------------------- > > Key: WFLY-5179 > URL: https://issues.jboss.org/browse/WFLY-5179 > Project: WildFly > Issue Type: Bug > Components: Test Suite > Reporter: Marek Kopecký > Assignee: Ondrej Kotek > > *Description of problem:* > Some tests are unable to init arquillian protocol with security manager. > *Affected tests found so far:* > * org.jboss.as.test.integration.ee.injection.resource.ejblocalref.EjbLocalRefInjectionTestCase#testEjbLink > * org.jboss.as.test.integration.ee.injection.resource.ejblocalref.EjbLocalRefInjectionTestCase#testLookup > * org.jboss.as.test.integration.ee.injection.resource.enventry.EnvEntryInjectionTestCase#testEnvEntryInjectionIntoServlet > * org.jboss.as.test.integration.ejb.security.AuthenticationTestCase > * org.jboss.as.test.xts.annotation.client.TransactionalTestCase#testNoTransaction > * org.jboss.as.test.xts.annotation.client.TransactionalTestCase#testActiveTransaction > *How reproducible:* > Always. > *Steps to Reproduce:* > # ./integration-tests.sh -fae -Dmaven.test.failure.ignore=true -Dnode0=$MYTESTIP_1 -Dnode1=$MYTESTIP_2 -DfailIfNoTests=false -Dsecurity.manager -Dts.basic -Dts.noSmoke -Dtest=EjbLocalRefInjectionTestCase > *Actual results:* > {noformat} > java.lang.RuntimeException: Could not init arquillian protocol > at org.xnio.Xnio.doGetInstance(Xnio.java:238) > at org.xnio.Xnio.getInstance(Xnio.java:193) > at org.jboss.remoting3.Remoting.createEndpoint(Remoting.java:112) > at org.jboss.as.controller.client.impl.RemotingModelControllerClient.getOrCreateChannel(RemotingModelControllerClient.java:122) > at org.jboss.as.controller.client.impl.RemotingModelControllerClient$1.getChannel(RemotingModelControllerClient.java:65) > at org.jboss.as.protocol.mgmt.ManagementChannelHandler.executeRequest(ManagementChannelHandler.java:147) > at org.jboss.as.protocol.mgmt.ManagementChannelHandler.executeRequest(ManagementChannelHandler.java:122) > at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeRequest(AbstractModelControllerClient.java:263) > at org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:168) > at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeForResult(AbstractModelControllerClient.java:147) > at org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:75) > at org.jboss.as.arquillian.container.ManagementClient.init(ManagementClient.java:140) > at org.jboss.as.arquillian.container.ManagementClient.getWebUri(ManagementClient.java:177) > at org.jboss.as.test.integration.ee.injection.resource.ejblocalref.EjbLocalRefInjectionTestCase.performCall(EjbLocalRefInjectionTestCase.java:62) > at org.jboss.as.test.integration.ee.injection.resource.ejblocalref.EjbLocalRefInjectionTestCase.testEjbLink(EjbLocalRefInjectionTestCase.java:73) > {noformat} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5428) Xml files from wildfly don't end with "new line character"

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/WFLY-5428?page=com.atlassian.jira.plugin.... ] Tomaz Cerar reassigned WFLY-5428: --------------------------------- Assignee: Tomaz Cerar (was: Paul Gier) > Xml files from wildfly don't end with "new line character" > ---------------------------------------------------------- > > Key: WFLY-5428 > URL: https://issues.jboss.org/browse/WFLY-5428 > Project: WildFly > Issue Type: Bug > Components: Build System > Affects Versions: 10.0.0.CR2 > Reporter: Marek Kopecký > Assignee: Tomaz Cerar > > *Description of problem:* > * Some of xml files from *wildfly* don't end with "new line character". > * Each xml file should end with "new line character", because of posix standard: > ** http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap03.html#t... > * List of affected files: > ** ./docs/examples/configs/standalone-gossip-ha.xml > ** ./docs/examples/configs/standalone-ec2-ha.xml > ** ./docs/examples/configs/standalone-picketlink.xml > ** ./docs/examples/configs/standalone-ec2-full-ha.xml > ** ./docs/examples/configs/standalone-rts.xml > ** ./docs/examples/configs/standalone-jts.xml > ** ./docs/examples/configs/standalone-xts.xml > ** ./docs/examples/configs/standalone-genericjms.xml > ** ./docs/examples/configs/standalone-gossip-full-ha.xml > ** ./standalone/configuration/standalone.xml > ** ./standalone/configuration/standalone-ha.xml > ** ./standalone/configuration/standalone-full.xml > ** ./standalone/configuration/standalone-full-ha.xml > *How reproducible:* > Always > *Steps to Reproduce:* > # cd EAP_HOME > # {noformat} > for xml in `find -type f | grep xml$`; do > if [ "`cat -E $xml | tail -n 1 |grep -o '.$'`" != "$" ] ; then > echo $xml > fi > done > {noformat} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1021) Xml files from wildfly-core don't end with "new line character"

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1021?page=com.atlassian.jira.plugi... ] Tomaz Cerar reassigned WFCORE-1021: ----------------------------------- Assignee: Tomaz Cerar (was: Paul Gier) > Xml files from wildfly-core don't end with "new line character" > --------------------------------------------------------------- > > Key: WFCORE-1021 > URL: https://issues.jboss.org/browse/WFCORE-1021 > Project: WildFly Core > Issue Type: Bug > Components: Server > Affects Versions: 2.0.0.CR5 > Reporter: Marek Kopecký > Assignee: Tomaz Cerar > > *Description of problem:* > * Some of xml files from *wildfly-core* don't end with "new line character". > * Each xml file should end with "new line character", because of posix standard: > ** http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap03.html#t... > * List of affected files: > ** ./modules/system/layers/base/org/wildfly/security/elytron/main/module.xml > ** ./domain/configuration/host.xml > ** ./domain/configuration/domain.xml > ** ./domain/configuration/host-slave.xml > ** ./domain/configuration/host-master.xml > ** ./standalone/configuration/standalone.xml > *How reproducible:* > Always > *Steps to Reproduce:* > # cd EAP_HOME > # {noformat} > for xml in `find -type f | grep xml$`; do > if [ "`cat -E $xml | tail -n 1 |grep -o '.$'`" != "$" ] ; then > echo $xml > fi > done > {noformat} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-708) Need to configure JAAS for host controller in host.xml

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFCORE-708?page=com.atlassian.jira.plugin... ] Darran Lofthouse resolved WFCORE-708. ------------------------------------- Fix Version/s: 2.0.0.CR6 Assignee: Darran Lofthouse Resolution: Won't Fix With ongoing changes this is not something we are planning to develop further. > Need to configure JAAS for host controller in host.xml > ------------------------------------------------------ > > Key: WFCORE-708 > URL: https://issues.jboss.org/browse/WFCORE-708 > Project: WildFly Core > Issue Type: Feature Request > Components: Domain Management, Security > Reporter: Hisanobu Okuda > Assignee: Darran Lofthouse > Fix For: 2.0.0.CR6 > > > I want to configure an advanced authentication for host controller as follow:- > (1) perform authentication against LDAP > (2) if (1) fails, perform authentication against properties file > To do this in domain mode, I need to set up a legacy JAAS config file and specify it via java.security.auth.login.config system property. It spoils maintainability and security of EAP6 in terms of:- > 1. unable to maintain it using jboss-cli.sh > 2. unable to use the vault feature for it -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ELY-298) load-from/uri keystore xsd/parser mismatch

by Kabir Khan (JIRA)

Kabir Khan created ELY-298: ------------------------------ Summary: load-from/uri keystore xsd/parser mismatch Key: ELY-298 URL: https://issues.jboss.org/browse/ELY-298 Project: WildFly Elytron Issue Type: Bug Reporter: Kabir Khan Assignee: Darran Lofthouse Fix For: 1.1.0.Alpha1 The xsd has {code} <xsd:complexType name="key-store-type"> <xsd:sequence minOccurs="1" maxOccurs="1">  <xsd:choice minOccurs="1" maxOccurs="1"> <xsd:element name="file" type="name-type" minOccurs="1" maxOccurs="1"/> <xsd:element name="load-from" type="uri-type" minOccurs="1" maxOccurs="1"/> <xsd:element name="resource" type="name-type" minOccurs="1" maxOccurs="1"/> {code} The parser seems to look for 'uri' rather than 'load-from' -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-1173) Remote/Local lookup with user authentication should work in the same way

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFLY-1173?page=com.atlassian.jira.plugin.... ] Darran Lofthouse resolved WFLY-1173. ------------------------------------ Fix Version/s: 10.0.0.Final Assignee: Darran Lofthouse Resolution: Out of Date > Remote/Local lookup with user authentication should work in the same way > ------------------------------------------------------------------------ > > Key: WFLY-1173 > URL: https://issues.jboss.org/browse/WFLY-1173 > Project: WildFly > Issue Type: Feature Request > Components: EE, Security > Environment: Testing on windows > Reporter: Fernando Rubbo > Assignee: Darran Lofthouse > Labels: local_interface, lookup > Fix For: 10.0.0.Final > > > I'm opening this issue because nobody was able to answer my question in the discussions section. So, I strongly believe this is an issue of the JBoss 7. > Let's to the issue: ctx.getCallerPrincipal() should work in the same way, no matter if it was a remote or a local lookup. For more details and an source code example, please see this thread: https://community.jboss.org/thread/202291 -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ELY-297) Account Lockout

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-297?page=com.atlassian.jira.plugin.sy... ] Darran Lofthouse commented on ELY-297: -------------------------------------- We need to consider some general 'defense' capabilities to support when using Elytron backed authentication. At the same time we need to ensure those measures don't become an opportunity for denial of service. Either way moved to Elytron as this is probably the correct place to consider this now. > Account Lockout > --------------- > > Key: ELY-297 > URL: https://issues.jboss.org/browse/ELY-297 > Project: WildFly Elytron > Issue Type: Task > Components: HTTP, Realms, SASL > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Labels: Common_Authentication, Realm_Management, management_security, > > One issue to consider is that we are using realms to integrate with existing user stores so may not be able to update the remote store: - > - Consider an option to update the remote store if possible. > - If not cache a backlisted user until an admin unlocks that account > Before being implemented this feature will require further discussion, in additional to locking mechanisms for unlocking should also be considered and also the potentional for denail of service type attacks based on locking out the administrators. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ELY-297) Implement an account lockout mechanism for domain management.

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-297?page=com.atlassian.jira.plugin.sy... ] Darran Lofthouse moved WFLY-569 to ELY-297: ------------------------------------------- Project: WildFly Elytron (was: WildFly) Key: ELY-297 (was: WFLY-569) Component/s: HTTP Realms SASL (was: Domain Management) (was: Security) Fix Version/s: (was: 11.0.0.Alpha1) > Implement an account lockout mechanism for domain management. > ------------------------------------------------------------- > > Key: ELY-297 > URL: https://issues.jboss.org/browse/ELY-297 > Project: WildFly Elytron > Issue Type: Task > Components: HTTP, Realms, SASL > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Labels: Common_Authentication, Realm_Management, management_security, > > One issue to consider is that we are using realms to integrate with existing user stores so may not be able to update the remote store: - > - Consider an option to update the remote store if possible. > - If not cache a backlisted user until an admin unlocks that account > Before being implemented this feature will require further discussion, in additional to locking mechanisms for unlocking should also be considered and also the potentional for denail of service type attacks based on locking out the administrators. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 7 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 September 2015