[JBoss JIRA] (ELY-57) Transition to enabling mechanisms to be 'managed' in server environment.
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/ELY-57?page=com.atlassian.jira.plugin.sys... ]
Darran Lofthouse moved SASL-66 to ELY-57:
-----------------------------------------
Project: WildFly Elytron (was: WildFly SASL Provider)
Key: ELY-57 (was: SASL-66)
Workflow: GIT Pull Request workflow (was: classic default workflow)
Fix Version/s: 1.0.0.Beta1
(was: 2.0.0.Alpha1)
> Transition to enabling mechanisms to be 'managed' in server environment.
> ------------------------------------------------------------------------
>
> Key: ELY-57
> URL: https://issues.jboss.org/browse/ELY-57
> Project: WildFly Elytron
> Issue Type: Task
> Security Level: Public(Everyone can see)
> Reporter: Darran Lofthouse
> Fix For: 1.0.0.Beta1
>
>
> For some mechanisms there is a fair amount of initialisation that needs to be performed each time the mechanism is used, e.g. for GSSAPI we have GSSName instances, GSSCredential instances etc...
> The existing convention for SASL mechanisms is that this initialisation occurs when the mechanism is instantiated which is at the time the relevant SaslServerFactory or SaslClientFactory is called. This convention really fits with the mechanisms being used in a JSE environment but once we move to a managed environment we are not so constrained.
> A few options: -
> - Provide a way a mechanism can cache something it has created so if called again it can re-use it.
> - Provide access to a factory / inject certain resources.
> - Make the mechanism fully managed in the server, when create is called the bulk of initialisation would have already occurred and what is returned handles the bare minimum state related to an authentication attemp (client or server side).
> One additional comment if we do consider something like this, some mechanisms may have items cached that once cached would never change for the lifetime of the process - for others we may have additional timeouts to consider such as Kerberos ticket expiration which may mean we want to regenerate cached resources at certain points.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 2 months
[JBoss JIRA] (ELY-59) Custom properties within mechanism selection
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/ELY-59?page=com.atlassian.jira.plugin.sys... ]
Darran Lofthouse moved SASL-65 to ELY-59:
-----------------------------------------
Project: WildFly Elytron (was: WildFly SASL Provider)
Key: ELY-59 (was: SASL-65)
Workflow: GIT Pull Request workflow (was: classic default workflow)
Component/s: SASL
(was: Util)
Fix Version/s: 1.0.0.Beta1
(was: 2.0.0.Alpha1)
> Custom properties within mechanism selection
> --------------------------------------------
>
> Key: ELY-59
> URL: https://issues.jboss.org/browse/ELY-59
> Project: WildFly Elytron
> Issue Type: Task
> Security Level: Public(Everyone can see)
> Components: SASL
> Reporter: Darran Lofthouse
> Fix For: 1.0.0.Beta1
>
>
> Some custom properties should maybe impact on mechanism selection e.g. wildfly.sasl.channel-binding.mode if set to required GSSAPI should be excluded as it does not support channel binding.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 2 months
[JBoss JIRA] (ELY-53) GSSAPI Make Delegated Credential Available
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/ELY-53?page=com.atlassian.jira.plugin.sys... ]
Darran Lofthouse moved SASL-68 to ELY-53:
-----------------------------------------
Project: WildFly Elytron (was: WildFly SASL Provider)
Key: ELY-53 (was: SASL-68)
Workflow: GIT Pull Request workflow (was: classic default workflow)
Component/s: SASL
(was: GSSAPI Mechanism)
Fix Version/s: 1.0.0.Beta1
(was: 2.0.0.Alpha1)
> GSSAPI Make Delegated Credential Available
> ------------------------------------------
>
> Key: ELY-53
> URL: https://issues.jboss.org/browse/ELY-53
> Project: WildFly Elytron
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: SASL
> Reporter: Darran Lofthouse
> Fix For: 1.0.0.Beta1
>
>
> The server side of the mechanism can receive a delegated credential but there is no way to obtain it, we should provide a way for it to be obtained or provided.
> _Note: This may be an Elytron integration point rather than something supported in the pure SASL mechanism._
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 2 months
[JBoss JIRA] (ELY-54) Support for stronger hashes as alternatives to MD5
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/ELY-54?page=com.atlassian.jira.plugin.sys... ]
Darran Lofthouse moved SASL-39 to ELY-54:
-----------------------------------------
Project: WildFly Elytron (was: WildFly SASL Provider)
Key: ELY-54 (was: SASL-39)
Workflow: GIT Pull Request workflow (was: classic default workflow)
Fix Version/s: 1.0.0.Beta1
(was: 2.0.0.Alpha1)
> Support for stronger hashes as alternatives to MD5
> --------------------------------------------------
>
> Key: ELY-54
> URL: https://issues.jboss.org/browse/ELY-54
> Project: WildFly Elytron
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Fix For: 1.0.0.Beta1
>
>
> Presently Digest authentication is based on MD5 - however we should either update the mechanism or add new mechanisms to support the use of stronger hashes.
> As this library is used both client and server side installations that require the stronger hashes can just ensure the client and server have the latest version of this library - installations that still require interaction with MD5 will need to ensure that it is still available as a mechanism.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 2 months
[JBoss JIRA] (ELY-49) Unable to build wildfly-sasl using the IBM JDK
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/ELY-49?page=com.atlassian.jira.plugin.sys... ]
Darran Lofthouse moved SASL-67 to ELY-49:
-----------------------------------------
Project: WildFly Elytron (was: WildFly SASL Provider)
Key: ELY-49 (was: SASL-67)
Workflow: GIT Pull Request workflow (was: classic default workflow)
Component/s: SASL
(was: Build)
Fix Version/s: 1.0.0.Beta1
(was: 2.0.0.Alpha1)
> Unable to build wildfly-sasl using the IBM JDK
> ----------------------------------------------
>
> Key: ELY-49
> URL: https://issues.jboss.org/browse/ELY-49
> Project: WildFly Elytron
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: SASL
> Environment: java version "1.7.0"
> Java(TM) SE Runtime Environment (build pxa6470_27-20131115_04)
> IBM J9 VM (build 2.7, JRE 1.7.0 Linux amd64-64 Compressed References 20131114_175264 (JIT enabled, AOT enabled)
> J9VM - R27_Java727_GA_20131114_0833_B175264
> JIT - tr.r13.java_20131113_50523
> GC - R27_Java727_GA_20131114_0833_B175264_CMPRSS
> J9CL - 20131114_175264)
> JCL - 20131113_01 based on Oracle 7u45-b18
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Fix For: 1.0.0.Beta1
>
>
> The build currently fails with the following error: -
> {noformat}
> [INFO] --- maven-resources-plugin:2.6:resources (default-resources) @ wildfly-sasl ---
> [INFO] Using 'UTF-8' encoding to copy filtered resources.
> [INFO] Copying 3 resources
> [INFO]
> [INFO] --- maven-compiler-plugin:3.1:compile (default-compile) @ wildfly-sasl ---
> [INFO] Changes detected - recompiling the module!
> [INFO] Compiling 47 source files to /home/darranl/src/wildfly/wildfly-sasl/target/classes
> [INFO]
> [INFO] --- maven-injection-plugin:1.0.2:bytecode (default) @ wildfly-sasl ---
> [INFO] ------------------------------------------------------------------------
> [INFO] BUILD FAILURE
> [INFO] ------------------------------------------------------------------------
> [INFO] Total time: 3.377 s
> [INFO] Finished at: 2014-06-25T11:42:26+00:00
> [INFO] Final Memory: 17M/34M
> [INFO] ------------------------------------------------------------------------
> [ERROR] Failed to execute goal org.jboss.maven.plugins:maven-injection-plugin:1.0.2:bytecode (default) on project wildfly-sasl: Unable to resolve class file path: NullPointerException -> [Help 1]
> [ERROR]
> {noformat}
> As the local testsuite now contains interoperability testing with JDK supplied implementations being able to run the build with other vendors implementations is important.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 2 months
[JBoss JIRA] (ELY-50) From RFC-2831 a realm name can contain whitespace, this means using space as the delimiter for possible realms is incorrect
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/ELY-50?page=com.atlassian.jira.plugin.sys... ]
Darran Lofthouse moved SASL-11 to ELY-50:
-----------------------------------------
Project: WildFly Elytron (was: WildFly SASL Provider)
Key: ELY-50 (was: SASL-11)
Workflow: GIT Pull Request workflow (was: classic default workflow)
Fix Version/s: 1.0.0.Beta1
(was: 2.0.0.Alpha1)
> From RFC-2831 a realm name can contain whitespace, this means using space as the delimiter for possible realms is incorrect
> ---------------------------------------------------------------------------------------------------------------------------
>
> Key: ELY-50
> URL: https://issues.jboss.org/browse/ELY-50
> Project: WildFly Elytron
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Fix For: 1.0.0.Beta1
>
>
> By using space as the separator a single realm name that contains a space is split into two realms.
> Either support quoted realm names if they contain a space or choose a different delimiter - (A different delimiter other than a control character may be difficult as the rest can appear in a realm name)
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 2 months