[JBoss JIRA] (ELY-257) Allow usage of properties to configure sasl server factories
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/ELY-257?page=com.atlassian.jira.plugin.sy... ]
Darran Lofthouse updated ELY-257:
---------------------------------
Fix Version/s: 1.1.0.Beta8
(was: 1.1.0.Beta7)
> Allow usage of properties to configure sasl server factories
> ------------------------------------------------------------
>
> Key: ELY-257
> URL: https://issues.jboss.org/browse/ELY-257
> Project: WildFly Elytron
> Issue Type: Feature Request
> Components: SASL
> Reporter: Kabir Khan
> Assignee: Darran Lofthouse
> Priority: Critical
> Fix For: 1.1.0.Beta8
>
>
> There is some discussion on https://github.com/wildfly-security/wildfly-elytron/pull/264. In this case the issue is that we have a ChannelBindingSaslServerFactory (and same for client) which provides a callback handler to deal with the channel binding callbacks needed by Gs2SaslServerFactory and Gs2SaslClientFactory. This is fine for when people create their own SaslServerFactory, and use that to create a SaslServer.
> However, if they want to call Sasl.createServer()/.createClient() they need to provide their own callback handler to deal with the channel binding types.
> One option would be to allow the usage of properties for this configuration needed by the factories.
> However, having slept on it, the callback handler passed in to Sasl.createXXX() would need to handle all callbacks. Is there a way to get a 'real' callback handler for a user wishing to instantiate clients/servers this way? Or is the intent that they have to write their own CBH?
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 5 months
[JBoss JIRA] (ELY-251) More certain credential based mechanism selection.
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/ELY-251?page=com.atlassian.jira.plugin.sy... ]
Darran Lofthouse updated ELY-251:
---------------------------------
Fix Version/s: 1.1.0.Beta8
(was: 1.1.0.Beta7)
> More certain credential based mechanism selection.
> --------------------------------------------------
>
> Key: ELY-251
> URL: https://issues.jboss.org/browse/ELY-251
> Project: WildFly Elytron
> Issue Type: Task
> Components: SASL
> Reporter: Darran Lofthouse
> Fix For: 1.1.0.Beta8
>
>
> When filtering authentication mechanisms we need to really be able to offer two modes: -
> 1 - Only offer a mech if we are sure it is supported.
> Risks only offering a weaker mechanism in a mixed domain but also eliminates mechanisms that could fail for a valid user that just happens to have a different credential type.
> 2- More general support.
> i.e. offer the mechs that may be supported.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 5 months
[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.1.0.Beta8
(was: 1.1.0.Beta7)
> 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
> Components: Authentication Client
> Reporter: David Lloyd
> Assignee: David Lloyd
> Fix For: 1.1.0.Beta8
>
>
> 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.4.11#64026)
8 years, 5 months
[JBoss JIRA] (ELY-298) load-from/uri keystore xsd/parser mismatch
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/ELY-298?page=com.atlassian.jira.plugin.sy... ]
Darran Lofthouse updated ELY-298:
---------------------------------
Fix Version/s: 1.1.0.Beta8
(was: 1.1.0.Beta7)
> load-from/uri keystore xsd/parser mismatch
> ------------------------------------------
>
> Key: ELY-298
> URL: https://issues.jboss.org/browse/ELY-298
> Project: WildFly Elytron
> Issue Type: Bug
> Components: Authentication Client
> Reporter: Kabir Khan
> Assignee: Darran Lofthouse
> Fix For: 1.1.0.Beta8
>
>
> The xsd has
> {code}
> <xsd:complexType name="key-store-type">
> <xsd:sequence minOccurs="1" maxOccurs="1">
> <!-- Access source type -->
> <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, 5 months
[JBoss JIRA] (ELY-279) Support CORS
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/ELY-279?page=com.atlassian.jira.plugin.sy... ]
Darran Lofthouse updated ELY-279:
---------------------------------
Fix Version/s: 1.1.0.Beta8
(was: 1.1.0.Beta7)
> Support CORS
> ------------
>
> Key: ELY-279
> URL: https://issues.jboss.org/browse/ELY-279
> Project: WildFly Elytron
> Issue Type: Feature Request
> Components: HTTP
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Fix For: 1.1.0.Beta8
>
>
> This is something that can possibly be tied in around the HTTP authentication framework meaning that the control of this can live in the HTTP authentication policy within Elytron rather than at the front end.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 5 months