[JBoss JIRA] (ELY-88) Command line utilities
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/ELY-88?page=com.atlassian.jira.plugin.sys... ]
Darran Lofthouse updated ELY-88:
--------------------------------
Fix Version/s: 1.2.0.Beta1
(was: 1.1.0.CR2)
> Command line utilities
> ----------------------
>
> Key: ELY-88
> URL: https://issues.jboss.org/browse/ELY-88
> Project: WildFly Elytron
> Issue Type: Feature Request
> Reporter: David Lloyd
> Assignee: Peter Skopek
> Fix For: 1.2.0.Beta1
>
>
> We should provide easy-to-use command line tools from the Elytron JAR as a main class that provide useful functions to users like:
> * Creating password hashes
> * Creating certificates and certificate requests
> * Creating key pairs of various types
> * Managing key stores (everything keytool does)
> * Get the library version
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 6 months
[JBoss JIRA] (ELY-118) Reloadable File-backed KeyStore
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/ELY-118?page=com.atlassian.jira.plugin.sy... ]
Darran Lofthouse resolved ELY-118.
----------------------------------
Resolution: Won't Do
> Reloadable File-backed KeyStore
> -------------------------------
>
> Key: ELY-118
> URL: https://issues.jboss.org/browse/ELY-118
> Project: WildFly Elytron
> Issue Type: Enhancement
> Components: KeyStores
> Reporter: David Lloyd
> Assignee: Darran Lofthouse
> Fix For: 1.1.0.CR2
>
>
> File-backed keystores can generically be made reloadable. This can be done by creating a KeyStore wrapper which contains an {{AtomicReference<KeyStore>}}. The wrapper also has a file name reference, and will initialize itself from that file. It would use an NIO.2 file watcher to monitor the file for changes; when the file is changed, the watcher attempts to re-load the file into a new KeyStore instance (using cached protection parameters). If successful, the new KeyStore replaces the old one atomically, providing atomic and clean real-time update capability.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 6 months
[JBoss JIRA] (ELY-97) Realm Readniess
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/ELY-97?page=com.atlassian.jira.plugin.sys... ]
Darran Lofthouse updated ELY-97:
--------------------------------
Fix Version/s: 1.2.0.Beta1
(was: 1.1.0.CR2)
> Realm Readniess
> ---------------
>
> Key: ELY-97
> URL: https://issues.jboss.org/browse/ELY-97
> Project: WildFly Elytron
> Issue Type: Feature Request
> Components: API / SPI
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Fix For: 1.2.0.Beta1
>
>
> Needs some discussion first but this is along the lines of the following: -
> 1 - Within WildFly where we currently have realms we have an ability to query them to check they are ready to handle requests - this is mainly used for out of the box where we can display an error page describing to the user additional steps they need to perform.
> 2 - Realms are essentially the interface to back end stores of user information, most likely being remote with no guarantee that they are always available, from an Elytron perspective this adds an additional two options: -
> i. Alter offered realms also taking into account availability, information disclosure risk but worth considering.
> ii. Security status panels within admin console, view at a glance what is available and what is not allowing administrator to take action. We also have notification support - a candidate for a notification.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 6 months
[JBoss JIRA] (ELY-121) Background initialization/pooling of SecureRandom
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/ELY-121?page=com.atlassian.jira.plugin.sy... ]
Darran Lofthouse updated ELY-121:
---------------------------------
Fix Version/s: 1.2.0.Beta1
(was: 1.1.0.CR2)
> Background initialization/pooling of SecureRandom
> -------------------------------------------------
>
> Key: ELY-121
> URL: https://issues.jboss.org/browse/ELY-121
> Project: WildFly Elytron
> Issue Type: Feature Request
> Components: Utils
> Reporter: David Lloyd
> Priority: Minor
> Fix For: 1.2.0.Beta1
>
>
> Provide a facility to initialize and pool SecureRandom instances in a background thread so that when things like SSLContexts are initialized, there are ready SecureRandoms. A background daemon thread which simply feeds instances into a modestly-sized BlockingQueue is probably more than adequate.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 6 months