[JBoss JIRA] (ELY-662) Eliminate CredentialStore interaction from within SASL mechanisms.
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/ELY-662?page=com.atlassian.jira.plugin.sy... ]
Darran Lofthouse updated ELY-662:
---------------------------------
Fix Version/s: 1.1.0.Beta25
(was: 1.1.0.Beta24)
> Eliminate CredentialStore interaction from within SASL mechanisms.
> ------------------------------------------------------------------
>
> Key: ELY-662
> URL: https://issues.jboss.org/browse/ELY-662
> Project: WildFly Elytron
> Issue Type: Enhancement
> Components: Credential Store, SASL
> Reporter: Darran Lofthouse
> Assignee: Peter Skopek
> Priority: Critical
> Fix For: 1.1.0.Beta25
>
>
> The conversion between callbacks and credential store should be handled centrally within the callback handler and not within the mechanism.
> This way all mechanisms can use the core integration including mechanisms that may not be Elytron aware just using standard Java callbacks.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (ELY-681) Hide private packages from generated javadoc.
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/ELY-681?page=com.atlassian.jira.plugin.sy... ]
Darran Lofthouse updated ELY-681:
---------------------------------
Fix Version/s: 1.1.0.Beta25
(was: 1.1.0.Beta24)
> Hide private packages from generated javadoc.
> ---------------------------------------------
>
> Key: ELY-681
> URL: https://issues.jboss.org/browse/ELY-681
> Project: WildFly Elytron
> Issue Type: Task
> Components: Build
> Reporter: Darran Lofthouse
> Priority: Critical
> Fix For: 1.1.0.Beta25
>
>
> We may want two profiles so we can generate a full javadoc and a 'public' javadoc.
> The 'public' javadoc should be the default one generated and should exclude the following packages: -
> org.wildfly.security._private
> org.wildfly.security.asn1
> org.wildfly.security.auth.realm
> org.wildfly.security.auth.realm.*
> org.wildfly.security.authz.jacc
> org.wildfly.security.credential.store.impl
> org.wildfly.security.security.digest
> org.wildfly.security.http.impl
> org.wildfly.security.security.keystore
> org.wildfly.security.mechanism.oauth2
> org.wildfly.security.mechanism.scram
> org.wildfly.security.password.impl
> org.wildfly.security.password.util
> org.wildfly.security.pem
> org.wildfly.security.sasl
> org.wildfly.security.sasl.* (Except util)
> org.wildfly.security.util
> org.wildfly.security.util_private
> org.wildfly.security.x500
> org.wildfly.security.x500.cert
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (ELY-726) Default Mechanism Ordering Implementation
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/ELY-726?page=com.atlassian.jira.plugin.sy... ]
Darran Lofthouse updated ELY-726:
---------------------------------
Fix Version/s: 1.1.0.Beta25
(was: 1.1.0.Beta24)
> Default Mechanism Ordering Implementation
> -----------------------------------------
>
> Key: ELY-726
> URL: https://issues.jboss.org/browse/ELY-726
> Project: WildFly Elytron
> Issue Type: Task
> Components: SASL
> Reporter: Darran Lofthouse
> Fix For: 1.1.0.Beta25
>
>
> We have to have some form of mechanism ordering anyway to get silent mechanisms to the front of the queue.
> SaslMechanismInformation may need some updates but we have plenty of information about the mechanisms so we should be able to put together a reasonable documented ordering.
> Stronger mechanisms that can complete without interaction with the client can be pulled up the list as they can quickly silently fail where AuthenticationClient does not have enough information to handle them. This set probably includes JBOSS_LOCAL_USER, EXTERNAL, GSSAPI, GS2, and the token mechs.
> For username / password mechanisms we can ensure PLAIN goes last.
> Of the CRAM, Digest, and SCRAM set I would suggest first order by digest algorithm and then SCRAM -> Digest -> CRAM.
> There will be the opportunity for plenty of discussions on is X really better than Y but I think a reasonable default implementation that is documented will be much better than today's current random ordering. Once filtering has been applied to take into account things like available credentials in the realms etc.
> I would expect most lists to be very small, maybe some silent mechs a token mech and one or two username / password mechs depending on consistency of an identity store.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (ELY-810) Unify CredentialStore around CredentialSource style storage capability
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/ELY-810?page=com.atlassian.jira.plugin.sy... ]
Darran Lofthouse updated ELY-810:
---------------------------------
Fix Version/s: 1.1.0.Beta25
(was: 1.1.0.Beta24)
> Unify CredentialStore around CredentialSource style storage capability
> ----------------------------------------------------------------------
>
> Key: ELY-810
> URL: https://issues.jboss.org/browse/ELY-810
> Project: WildFly Elytron
> Issue Type: Task
> Components: Credential Store
> Reporter: David Lloyd
> Assignee: David Lloyd
> Fix For: 1.1.0.Beta25
>
>
> The following needs to be done:
> * Move the PB masked password format to a proper password type
> * Introduce protection parameters for credential stores and entries
> * Drop the admin_key concept in favor of credential store protection parameters
> * Introduce a proper vault-compatible credential store
> * Introduce a mechanism to pull protection parameters for stores from the client configuration
> * Use a credential store which can store (nearly) any credential type
> * Update XML accordingly
> * Remove dangerous command execution patterns from credential store, make them safe and make them CredentialSources instead
> * Clean up exception hierarchy of credential stores
> * Introduce simple map-backed credential store
> Additionally, the above implies:
> * Introduce AlgorithmParameterSpi for password parameter types
> * Introduce hashing ability for parameters
> * Add missing parameter types for PBE
> * Introduce serialization trickery to support picketbox class names for vault files
> * Atomic file output stream
> * Update tests as needed
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months