[JBoss JIRA] (ELY-25) Authentication (and identity loading) lifecycle.
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/ELY-25?page=com.atlassian.jira.plugin.sys... ]
Darran Lofthouse resolved ELY-25.
---------------------------------
Resolution: Out of Date
> Authentication (and identity loading) lifecycle.
> ------------------------------------------------
>
> Key: ELY-25
> URL: https://issues.jboss.org/browse/ELY-25
> Project: WildFly Elytron
> Issue Type: Task
> Components: API / SPI
> Reporter: Darran Lofthouse
> Fix For: 1.1.0.CR2
>
>
> Just a place holder to think about this one, anything involved in the process may need to know when the current round trip finishes.
> e.g. Once an LDAP connection is obtained we may want to cache it for the duration of the request which means we need to clean it up at the appropriate time.
> Alternatively some form of pool may be sufficient but just raising this issue so we ensure it is covered one way or another.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 5 months
[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, 5 months
[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, 5 months
[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, 5 months
[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, 5 months