June 2017 - jboss-jira - Jboss List Archives

[JBoss JIRA] (ELY-23) Add support for RFC5803

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-23?page=com.atlassian.jira.plugin.sys... ] Darran Lofthouse updated ELY-23: -------------------------------- Fix Version/s: 1.2.0.Beta1 (was: 1.1.0.CR2) > Add support for RFC5803 > ----------------------- > > Key: ELY-23 > URL: https://issues.jboss.org/browse/ELY-23 > Project: WildFly Elytron > Issue Type: Sub-task > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 1.2.0.Beta1 > > > RFC5803 adds support for storing SCRAM secrets in the 'authPassword' attribute introduced by RFC3112 -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ELY-22) Expand LDAP realm to support RFC3112

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-22?page=com.atlassian.jira.plugin.sys... ] Darran Lofthouse updated ELY-22: -------------------------------- Fix Version/s: 1.2.0.Beta1 (was: 1.1.0.CR2) > Expand LDAP realm to support RFC3112 > ------------------------------------ > > Key: ELY-22 > URL: https://issues.jboss.org/browse/ELY-22 > Project: WildFly Elytron > Issue Type: Sub-task > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 1.2.0.Beta1 > > > RFC3112 adds a new attribute 'authPassword' and can be used to store passwords in various formats. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ELY-13) Interoperability testing with KeyCloak

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-13?page=com.atlassian.jira.plugin.sys... ] Darran Lofthouse resolved ELY-13. --------------------------------- Resolution: Done > Interoperability testing with KeyCloak > -------------------------------------- > > Key: ELY-13 > URL: https://issues.jboss.org/browse/ELY-13 > Project: WildFly Elytron > Issue Type: Sub-task > Reporter: Darran Lofthouse > Assignee: Pedro Igor > Fix For: 1.1.0.CR2 > > -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ELY-30) Authentication and establisment of IdentityContext as the authenticated identity.

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-30?page=com.atlassian.jira.plugin.sys... ] Darran Lofthouse resolved ELY-30. --------------------------------- Resolution: Out of Date > Authentication and establisment of IdentityContext as the authenticated identity. > --------------------------------------------------------------------------------- > > Key: ELY-30 > URL: https://issues.jboss.org/browse/ELY-30 > Project: WildFly Elytron > Issue Type: Sub-task > Components: Testsuite > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 1.1.0.CR2 > > -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ELY-29) Common Use Cases

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-29?page=com.atlassian.jira.plugin.sys... ] Darran Lofthouse resolved ELY-29. --------------------------------- Resolution: Done > Common Use Cases > ---------------- > > Key: ELY-29 > URL: https://issues.jboss.org/browse/ELY-29 > Project: WildFly Elytron > Issue Type: Task > Components: Testsuite > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 1.1.0.CR2 > > > The API/SPI of Elytron is based around numerous discussions on the scenarios we need to support in an application server environment - this is a parent task to start adding some test cases that cover these scenarios. > Any subsequent API evolution has to take into account the scenarios we must - this will also be key to identifying backwards compatibility going forward. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ELY-27) Permissions Checks

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-27?page=com.atlassian.jira.plugin.sys... ] Darran Lofthouse resolved ELY-27. --------------------------------- Resolution: Done > Permissions Checks > ------------------ > > Key: ELY-27 > URL: https://issues.jboss.org/browse/ELY-27 > Project: WildFly Elytron > Issue Type: Task > Components: API / SPI > Reporter: Darran Lofthouse > Fix For: 1.1.0.CR2 > > -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9036) TransactionAttribute annotation is inherited from interface which not according to the spec

by Wolf-Dieter Fink (JIRA)

Wolf-Dieter Fink created WFLY-9036: -------------------------------------- Summary: TransactionAttribute annotation is inherited from interface which not according to the spec Key: WFLY-9036 URL: https://issues.jboss.org/browse/WFLY-9036 Project: WildFly Issue Type: Bug Components: EJB Affects Versions: 10.1.0.Final, 11.0.0.Alpha1 Reporter: Wolf-Dieter Fink The annotation @TransactionAttribute is inherited from the business interface which is not according to the EJB specification. Any annotation on the bean's implemenation class or deployment descriptor is overridden if the Interface is annotated with @TransactionAttribute The EJB 3.2 specification chapter 8.3.7 says "For a session bean written to the EJB 3.x client view API, the transaction attributes are speci- fied for those methods of the session bean class that correspond to the bean’s business inter- face" Also the Javadoc for TransactionAttribute (http://docs.oracle.com/javaee/7/api/javax/ejb/TransactionAttribute.html) mention the bean class only. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9035) TransactionAttribute annotation is inherited from interface which not according to the spec

by Wolf-Dieter Fink (JIRA)

Wolf-Dieter Fink created WFLY-9035: -------------------------------------- Summary: TransactionAttribute annotation is inherited from interface which not according to the spec Key: WFLY-9035 URL: https://issues.jboss.org/browse/WFLY-9035 Project: WildFly Issue Type: Bug Components: EJB Affects Versions: 11.0.0.Alpha1, 10.1.0.Final Reporter: Wolf-Dieter Fink The annotation @TransactionAttribute is inherited from the business interface which is not according to the EJB specification. Any annotation on the bean's implemenation class or deployment descriptor is overridden if the Interface is annotated with @TransactionAttribute The EJB 3.2 specification chapter 8.3.7 says "For a session bean written to the EJB 3.x client view API, the transaction attributes are speci- fied for those methods of the session bean class that correspond to the bean’s business inter- face" Also the Javadoc for TransactionAttribute (http://docs.oracle.com/javaee/7/api/javax/ejb/TransactionAttribute.html) mention the bean class only. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ELY-41) Password Recognition and Parsing Framework

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-41?page=com.atlassian.jira.plugin.sys... ] Darran Lofthouse resolved ELY-41. --------------------------------- Resolution: Won't Do > Password Recognition and Parsing Framework > ------------------------------------------ > > Key: ELY-41 > URL: https://issues.jboss.org/browse/ELY-41 > Project: WildFly Elytron > Issue Type: Task > Components: API / SPI > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 1.1.0.CR2 > > > I don't think having a single PasswordUtils that recognises and parses all password types is going to be a good idea long term - I think a lot of the responsibility for what is supported needs to come from the realm. > A scenario I am thinking is an LDAP server is configured to support clear text passwords, that server verifies the strength of the password before letting a user set it - this could be circumvented by setting the password value to something we would parse as one of the other password types. The problem is the user could just hash 'password' - this would pass the LDAP servers dictionary attack check. > The second issue is that different formats could be realm specific, e.g. LDAP supports trival digests in formats slightly different to those we already support. > One idea I am starting to think about it a password parser that a realm can build up with a set of supported password types, working on LDAP it is apparent realms potentially need configuration for the credential types they will claim to support before the RealmIdentity is identified so not a major deviation from the work I am already finding necessary. > Looking at the current PasswordUtils.java the following public utility methods are exposed: - > {code} > org.wildfly.security.password.PasswordUtils > org.wildfly.security.password.PasswordUtils.identifyAlgorithm(char[]) > org.wildfly.security.password.PasswordUtils.identifyAlgorithm(String) > org.wildfly.security.password.PasswordUtils.getCryptStringChars(PasswordSpec) > org.wildfly.security.password.PasswordUtils.getCryptString(PasswordSpec) > org.wildfly.security.password.PasswordUtils.parseCryptString(String) > org.wildfly.security.password.PasswordUtils.parseCryptString(char[]) > {code} > From the perspective of a realm the primary task I am trying to achieve is to take a password string and convert it to a PasswordSpec. Algorithm identification seems to be used primarily by tests, not convinced it is justified in an API. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ELY-36) Server Authentication Context Lifecycle

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-36?page=com.atlassian.jira.plugin.sys... ] Darran Lofthouse resolved ELY-36. --------------------------------- Resolution: Out of Date > Server Authentication Context Lifecycle > --------------------------------------- > > Key: ELY-36 > URL: https://issues.jboss.org/browse/ELY-36 > Project: WildFly Elytron > Issue Type: Task > Components: API / SPI > Reporter: Darran Lofthouse > Fix For: 1.1.0.CR2 > > > The authentication context is used with a sequence of calls during the authentication process, this task is to look into how we can apply a lifecycle to that so that appropriate clean up can be performed. > This could be closely related to ELY-35 which specifically looks at outcome notification. > When considering a lifecycle I think we have two key events to think about, the most natural one being once the authentication process is complete regardless of outcome - however should also consider intermediate responses going back to the client - we do not want to be holding onto expensive resources once we pass control back to the client as that risks a Dos based attack. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 4 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 June 2017