[JBoss JIRA] (ELY-377) Add a SecurityFactory implementation to return a GSSCredential
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/ELY-377?page=com.atlassian.jira.plugin.sy... ]
Darran Lofthouse updated ELY-377:
---------------------------------
Fix Version/s: 1.1.0.Beta5
(was: 1.1.0.Beta4)
> Add a SecurityFactory implementation to return a GSSCredential
> --------------------------------------------------------------
>
> Key: ELY-377
> URL: https://issues.jboss.org/browse/ELY-377
> Project: WildFly Elytron
> Issue Type: Task
> Components: Utils
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Fix For: 1.1.0.Beta5
>
>
> This task is for a simple implementation that uses a JAAS call and the GSSAPI APIs to authenticate and obtain the GSSCredential.
> For completeness this utility should probably cover both the client side and server side use cases.
> Delegation however may call for a slightly different implement for the client side when running in a server.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 months
[JBoss JIRA] (ELY-376) Password policies
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/ELY-376?page=com.atlassian.jira.plugin.sy... ]
Darran Lofthouse updated ELY-376:
---------------------------------
Fix Version/s: 1.1.0.Beta5
(was: 1.1.0.Beta4)
> Password policies
> -----------------
>
> Key: ELY-376
> URL: https://issues.jboss.org/browse/ELY-376
> Project: WildFly Elytron
> Issue Type: Feature Request
> Components: API / SPI, Passwords, Realms
> Reporter: Darran Lofthouse
> Assignee: David Lloyd
> Fix For: 1.1.0.Beta5
>
>
> Probably needs a design discussion first but we need to review where password policies fit in to the overall solution.
> We may say that policy handling is really the responsibility of the actual realm implementation, after all items such as history are going to be very realm specific.
> However there may also be a case in the generic sense that where a modifiable realm is in use a policy is desired to cover the complexity of any passwords set on that realm.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 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.1.0.Beta5
(was: 1.1.0.Beta4)
> 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
> Components: API / SPI
> Reporter: David Lloyd
> Priority: Critical
> Fix For: 1.1.0.Beta5
>
>
> 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.4.11#64026)
10 years, 2 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.Beta5
(was: 1.1.0.Beta4)
> 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.Beta5
>
>
> 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)
10 years, 2 months
[JBoss JIRA] (ELY-151) Ability to supply additional information during credential acquisition
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/ELY-151?page=com.atlassian.jira.plugin.sy... ]
Darran Lofthouse updated ELY-151:
---------------------------------
Fix Version/s: 1.1.0.Beta5
(was: 1.1.0.Beta4)
> Ability to supply additional information during credential acquisition
> ----------------------------------------------------------------------
>
> Key: ELY-151
> URL: https://issues.jboss.org/browse/ELY-151
> Project: WildFly Elytron
> Issue Type: Enhancement
> Components: API / SPI, Passwords
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Fix For: 1.1.0.Beta5
>
>
> I think this is the final known gap in our credential acquisition and validation API/SPI.
> There are a couple of specifications that also allow for additional information to be used when obtaining a representation of a users credential, the most obvious being the session based variant of digest authentication where a nonce and cnonce are also incorporated.
> A second variant with two different modes of operation would be the realm associated with the digest credential, currently we assume it is tightly associated with the storage representation of the credential but it could also be the case that the mech is requesting it for a specific realm.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 months