[JBoss JIRA] (ELY-212) Client-side SSL context configuration is subtly wrong
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/ELY-212?page=com.atlassian.jira.plugin.sy... ]
Darran Lofthouse updated ELY-212:
---------------------------------
Fix Version/s: 1.0.0.Alpha5
> Client-side SSL context configuration is subtly wrong
> -----------------------------------------------------
>
> Key: ELY-212
> URL: https://issues.jboss.org/browse/ELY-212
> Project: WildFly Elytron
> Issue Type: Bug
> Reporter: David Lloyd
> Assignee: David Lloyd
> Fix For: 1.0.0.Alpha5
>
>
> SSL context client-side configuration is problematic in that the SSL context is not (and cannot be) cached. This means that we lose SSL session reuse and other benefits which may cause problems for users.
> However we also cannot just cache an SSL context on a configuration either - the client credentials may vary on each request, causing leakage between identities.
> What we need to do is have a separate SSL context client configuration mechanism, and use the generic client context configuration to reference this SSL context client configuration.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 11 months
[JBoss JIRA] (ELY-221) Implement a better X.500 principal mapper
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/ELY-221?page=com.atlassian.jira.plugin.sy... ]
Darran Lofthouse updated ELY-221:
---------------------------------
Fix Version/s: 1.0.0.Alpha5
> Implement a better X.500 principal mapper
> -----------------------------------------
>
> Key: ELY-221
> URL: https://issues.jboss.org/browse/ELY-221
> Project: WildFly Elytron
> Issue Type: Feature Request
> Reporter: David Lloyd
> Fix For: 1.0.0.Alpha5
>
>
> We can provide something better than a flat string mapping. Some thoughts on requirements:
> * Require that a minimum set of keys are present, else return {{null}}
> * Allow piecewise assembly of principal names with the following components:
> ** Static string
> ** Single attribute value e.g. {{dc[0]}}
> ** Joined attribute value (with optional subrange) e.g. {{dc:"."}} would convert {{dc=example,dc=com}} to {{example.com}}
> ** Joined attribute value in reverse (with optional subrange)
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 11 months
[JBoss JIRA] (ELY-234) Implement SPKM-1 GSS mechanism and GSS-K7XIDASOVRG3BZSQ and GS2-DT4PIK22T6APV2PY SASL mechanisms
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/ELY-234?page=com.atlassian.jira.plugin.sy... ]
Darran Lofthouse updated ELY-234:
---------------------------------
Fix Version/s: 2.0.0.Alpha1
> Implement SPKM-1 GSS mechanism and GSS-K7XIDASOVRG3BZSQ and GS2-DT4PIK22T6APV2PY SASL mechanisms
> ------------------------------------------------------------------------------------------------
>
> Key: ELY-234
> URL: https://issues.jboss.org/browse/ELY-234
> Project: WildFly Elytron
> Issue Type: Task
> Components: SASL
> Reporter: David Lloyd
> Fix For: 2.0.0.Alpha1
>
>
> Implement the "Simple Private Key" GSSAPI mechanism. This can be done in one of two ways:
> # Implement SPKM as a GSSAPI mechanism, and let the GSSAPI and GS2 SASL mechanism factories automatically pick it out.
> # Implement SPKM directly in SASL as "GS2-DT4PIK22T6APV2PY" and do not provide GSSAPI support for other GSSAPI consumers.
> SPKM-1 supports unilateral and mutual authentication using keys. SPKM-3 supports key-based server authentication and password-based client authentication.
> Background reading:
> * The Simple Public-Key GSS-API Mechanism (SPKM): https://tools.ietf.org/html/rfc2025
> * Using Generic Security Service Application Program Interface (GSS-API) Mechanisms in Simple Authentication and Security Layer (SASL): The GS2 Mechanism Family: https://tools.ietf.org/html/rfc5801
> * LIPKEY - A Low Infrastructure Public Key Mechanism Using SPKM: https://tools.ietf.org/html/rfc2847 (also referred to as SPKM-3)
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 11 months