September 2015 - jboss-jira - Jboss List Archives

[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)

8 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)

8 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)

8 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)

8 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 updated ELY-297: --------------------------------- Summary: Account Lockout (was: Implement an account lockout mechanism for domain management.) > 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)

8 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4872) Add the Elytron subsystem to the feature packs

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFLY-4872?page=com.atlassian.jira.plugin.... ] Darran Lofthouse commented on WFLY-4872: ---------------------------------------- So far we create custom standalone-elytron.xml, host-elytron.xml and domain-elytron.xml configurations - at some point we will pull these changes into the actual configurations. > Add the Elytron subsystem to the feature packs > ---------------------------------------------- > > Key: WFLY-4872 > URL: https://issues.jboss.org/browse/WFLY-4872 > Project: WildFly > Issue Type: Sub-task > Components: Build System > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 11.0.0.Alpha1 > > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5431) Enable Elytron backed security for Undertow handled deployments.

by Darran Lofthouse (JIRA)

Darran Lofthouse created WFLY-5431: -------------------------------------- Summary: Enable Elytron backed security for Undertow handled deployments. Key: WFLY-5431 URL: https://issues.jboss.org/browse/WFLY-5431 Project: WildFly Issue Type: Sub-task Components: Web (Undertow) Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 11.0.0.Alpha1 -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-747) Dynamic Detection of SPNEGO auth method and adding of NegotiationAuthenticator

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFLY-747?page=com.atlassian.jira.plugin.s... ] Darran Lofthouse resolved WFLY-747. ----------------------------------- Fix Version/s: 10.0.0.Final (was: Awaiting Volunteers) Assignee: Darran Lofthouse Resolution: Duplicate Issue SPNEGO authentication has been added to WildFly 10 so no further special handling required. > Dynamic Detection of SPNEGO auth method and adding of NegotiationAuthenticator > ------------------------------------------------------------------------------ > > Key: WFLY-747 > URL: https://issues.jboss.org/browse/WFLY-747 > Project: WildFly > Issue Type: Task > Components: Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 10.0.0.Final > > > Previously a mapping for the SPNEGO auth method and the authenticator had to be manually defined, this capability is not present in AS7 however it is suggested that alternatively we can detect the auth method ourselves and dynamically add the valve - this seems cleaner as it potentially allows SPNEGO to be added/removed from a server without manual configuration being required. > It is suggested to look at the following code for an example where a valve has been added dynamically before: - > org.jboss.as.jpa.processor.PersistenceUnitDeploymentProcessor in the JPA subsystem. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-899) spelling mistakes in the management security domain should be logged better

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFLY-899?page=com.atlassian.jira.plugin.s... ] Darran Lofthouse resolved WFLY-899. ----------------------------------- Release Notes Text: Marking as out of date as across the application server we are moving to a new capability and requirement model to handle the dependencies between resources. The error reporting and level of any additional helpful messages to say suggest available alternatives should be a part of the general capabilities / requirements handling. Fix Version/s: 10.0.0.Final Resolution: Out of Date > spelling mistakes in the management security domain should be logged better > --------------------------------------------------------------------------- > > Key: WFLY-899 > URL: https://issues.jboss.org/browse/WFLY-899 > Project: WildFly > Issue Type: Feature Request > Components: Security, Server > Reporter: Tom Fonteyne > Assignee: Darran Lofthouse > Priority: Minor > Fix For: 10.0.0.Final > > > A spelling mistake in the management security domain prevents the server from starting (good) but the message in the log file is only stating: > [Host Controller] 08:35:37,672 FATAL [org.jboss.as.host.controller] (Controller Boot Thread) JBAS010933: Host Controller boot has failed in an unrecoverable manner; exiting. See previous messages for details. > There in fact no previous messages -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5154) DenyModulePermissionsTestCase, GrantModulePermissionsTestCase, LimitedModulePermissionsTestCase cannot deploy jar

by Marek Kopecký (JIRA)

[ https://issues.jboss.org/browse/WFLY-5154?page=com.atlassian.jira.plugin.... ] Marek Kopecký updated WFLY-5154: -------------------------------- Attachment: GrantModulePermissionsTestCase.stacktrace.txt > DenyModulePermissionsTestCase, GrantModulePermissionsTestCase, LimitedModulePermissionsTestCase cannot deploy jar > ----------------------------------------------------------------------------------------------------------------- > > Key: WFLY-5154 > URL: https://issues.jboss.org/browse/WFLY-5154 > Project: WildFly > Issue Type: Bug > Components: Test Suite > Reporter: Marek Kopecký > Assignee: Josef Cacek > Fix For: 10.0.0.CR2 > > Attachments: GrantModulePermissionsTestCase.stacktrace.txt > > > *Description of problem* > * org.jboss.as.testsuite.integration.secman.module.DenyModulePermissionsTestCase > ** fails with Cannot deploy: modperm-deny.jar > * org.jboss.as.testsuite.integration.secman.module.GrantModulePermissionsTestCase > ** fails with Cannot deploy: modperm-grant.jar > * org.jboss.as.testsuite.integration.secman.module.LimitedModulePermissionsTestCase > ** fails with Cannot deploy: modperm-limited.jar > *How reproducible* > * 15% > * OpenJDK, IBM JDK, Oracle JDK > * Solaris, Windows, RHEL > > *Expected results* > No failures in test case. > *Additional info* > See for server logs for DenyModulePermissionsTestCase in attachment -- This message was sent by Atlassian JIRA (v6.4.11#64026)

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