[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: 2.0.0.Alpha1
(was: 1.1.0.Beta15)
> 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: 2.0.0.Alpha1
>
>
> 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
(v7.2.3#72005)
9 years, 8 months
[JBoss JIRA] (WFCORE-1958) Clean up testsuite Elytron Registration
by Darran Lofthouse (JIRA)
Darran Lofthouse created WFCORE-1958:
----------------------------------------
Summary: Clean up testsuite Elytron Registration
Key: WFCORE-1958
URL: https://issues.jboss.org/browse/WFCORE-1958
Project: WildFly Core
Issue Type: Task
Components: Test Suite
Reporter: Darran Lofthouse
Assignee: Darran Lofthouse
Priority: Blocker
Fix For: 3.0.0.Alpha12
In a couple of places we have artificially registered the WildFly Elytron Security provider, we need to address this so tests can automatically have it available to them..
Also re-enable the following test case: -
* org.jboss.as.test.integration.domain.suites.FullRbacProviderRunAsTestSuite
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 8 months
[JBoss JIRA] (WFCORE-1958) Clean up testsuite Elytron registration
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1958?page=com.atlassian.jira.plugi... ]
Darran Lofthouse updated WFCORE-1958:
-------------------------------------
Summary: Clean up testsuite Elytron registration (was: Clean up testsuite Elytron Registration)
> Clean up testsuite Elytron registration
> ---------------------------------------
>
> Key: WFCORE-1958
> URL: https://issues.jboss.org/browse/WFCORE-1958
> Project: WildFly Core
> Issue Type: Task
> Components: Test Suite
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Priority: Blocker
> Fix For: 3.0.0.Alpha12
>
>
> In a couple of places we have artificially registered the WildFly Elytron Security provider, we need to address this so tests can automatically have it available to them..
> Also re-enable the following test case: -
> * org.jboss.as.test.integration.domain.suites.FullRbacProviderRunAsTestSuite
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 8 months
[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 resolved ELY-257.
----------------------------------
Resolution: Out of Date
Resolving as out of date, properties can be provided to all mechanisms. Will create new issues if we have any ongoing issues.
> 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.Beta15
>
>
> 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
(v7.2.3#72005)
9 years, 8 months
[JBoss JIRA] (ELY-573) Programatic authentication
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/ELY-573?page=com.atlassian.jira.plugin.sy... ]
Darran Lofthouse updated ELY-573:
---------------------------------
Fix Version/s: 1.1.0.Beta13
(was: 1.1.0.Beta15)
> Programatic authentication
> --------------------------
>
> Key: ELY-573
> URL: https://issues.jboss.org/browse/ELY-573
> Project: WildFly Elytron
> Issue Type: Enhancement
> Components: HTTP
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Priority: Critical
> Fix For: 1.1.0.Beta13
>
>
> This is critical as it risks changing defined APIs and SPIs but we need to cover programatic authentication.
> It is however possible this is handled within the app server integration and not within our framework but we have two predominant cases: -
> - Servlet calls authenticate which means our mechanisms need to be triggered to challenge the client.
> - Servlet calls login with a username and password.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 8 months
[JBoss JIRA] (WFLY-7522) Definition Elytron key-manager with key-store (which needs password) without filled credential-reference causes ugly failure-description with senseless Exception.
by Hynek Švábek (JIRA)
Hynek Švábek created WFLY-7522:
----------------------------------
Summary: Definition Elytron key-manager with key-store (which needs password) without filled credential-reference causes ugly failure-description with senseless Exception.
Key: WFLY-7522
URL: https://issues.jboss.org/browse/WFLY-7522
Project: WildFly
Issue Type: Bug
Components: Security
Reporter: Hynek Švábek
Assignee: Darran Lofthouse
Definition Elytron key-manager with key-store (which needs password) without filled credential-reference causes ugly failure-description with senseless Exception.
*Steps to reproduce*
* firefly.keystore which is attached copy to eap_home/standalone/data/cs.
* /subsystem=elytron/key-store=ff001:add(path=cs/firefly.keystore,relative-to=jboss.server.data.dir,type=JKS,credential-reference= {clear-text=Elytron})
*/subsystem=elytron/key-managers=keymanager001:add(algorithm=SunX509, key-store=ff001)
And you get this output:
{code}
{
"outcome" => "failed",
"failure-description" => {
"WFLYCTL0080: Failed services" => {"org.wildfly.security.key-managers.km002" => "org.jboss.msc.service.StartException in service org.wildfly.security.key-managers.km002: Failed to start service
Caused by: java.lang.NullPointerException"},
"WFLYCTL0412: Required services that are not installed:" => ["org.wildfly.security.key-managers.km002"],
"WFLYCTL0180: Services with missing/unavailable dependencies" => undefined
},
"rolled-back" => true
}
{code}
There must be some kind of information about missing credential-reference or at least missing (wrong) password to key-store.
When I add there credential-reference with pass to Key-store then operation passes
/subsystem=elytron/key-managers=keymanager001:add(algorithm=SunX509, key-store=ff001, credential-reference={clear-text=Elytron})
*Suggestions to improvement*
failure-description must not contain Exception or snippet stacktrace.
Please replace WFLYCTL0080 part to better message.
e.g. "credential-reference is required", "Missing password to key-store access"
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 8 months
[JBoss JIRA] (WFLY-7520) VisualVM connection not possible in domain mode
by Gunther v. Wolffersdorff (JIRA)
[ https://issues.jboss.org/browse/WFLY-7520?page=com.atlassian.jira.plugin.... ]
Gunther v. Wolffersdorff updated WFLY-7520:
-------------------------------------------
Steps to Reproduce:
These steps work fine using Wildfly 8.2.0.Final and does not work anymore using
Wildfly 10.1.0.Final:
{code}
cd WF_HOME
bin\add-user.bat -a monitor monitor
{code}
in other window start default domain configuration:
{code}
bin\domain.bat
{code}
via CLI do these config changes
{code}
bin\jboss-cli.bat --connect
/profile=full/subsystem=jmx/remoting-connector=jmx:add
/profile=full/subsystem=jmx/remoting-connector=jmx:write-attribute(name=use-management-endpoint, value=false)
/server-group=main-server-group:reload-servers
{code}
Now you should be able to connect to server-one with VisualVM by
*service:jmx:http-remoting-jmx://127.0.0.1:8080* as user *monitor*.
Again this works fine using Wildfly 8.2.0.Final and does not work anymore with Wildfly
10.1.0.Final.
These steps are for simplification purposes. Also we cannot monitor a domain server in case of different master and slave hosts.
was:
These steps work fine using Wildfly 8.2.0.Final and does not work anymore using
Wildfly 10.1.0.Final:
{code}
cd WF_HOME
bin\add-user.bat -a monitor monitor
{code}
in other window start default domain configuration:
{code}
bin\domain.bat
{code}
via CLI do these config changes
{code}
bin\jboss-cli.bat --connect
/profile=full/subsystem=jmx/remoting-connector=jmx:add
/profile=full/subsystem=jmx/remoting-connector=jmx:write-attribute(name=use-management-endpoint, value=false)
/server-group=main-server-group:reload-servers
{code}
Now you should be able to connect to server-one with VisualVM by
service:jmx:http-remoting-jmx://127.0.0.1:8080 as user monitor.
Again this works fine using Wildfly 8.2.0.Final and does not work anymore with Wildfly
10.1.0.Final.
> VisualVM connection not possible in domain mode
> -----------------------------------------------
>
> Key: WFLY-7520
> URL: https://issues.jboss.org/browse/WFLY-7520
> Project: WildFly
> Issue Type: Bug
> Components: JMX, Remoting
> Affects Versions: 10.1.0.Final
> Environment: Java version: 1.8.0_45, vendor: Oracle Corporation
> Java home: C:\Program Files\Java\jdk1.8.0_45\jre
> Default locale: de_DE, platform encoding: Cp1252
> OS name: "windows 8.1", version: "6.3", arch: "amd64", family: "dos"
> Reporter: Gunther v. Wolffersdorff
> Assignee: Kabir Khan
> Labels: JMX, VisualVM
>
> VisualVM cannot connect to domain host server via service:jmx:http-remoting-jmx .
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 8 months
[JBoss JIRA] (ELY-509) Multi Step HTTP Authentication
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/ELY-509?page=com.atlassian.jira.plugin.sy... ]
Darran Lofthouse updated ELY-509:
---------------------------------
Fix Version/s: 2.0.0.Alpha1
(was: 1.1.0.Beta14)
> Multi Step HTTP Authentication
> ------------------------------
>
> Key: ELY-509
> URL: https://issues.jboss.org/browse/ELY-509
> Project: WildFly Elytron
> Issue Type: Enhancement
> Components: HTTP
> Reporter: Darran Lofthouse
> Assignee: Farah Juma
> Fix For: 2.0.0.Alpha1
>
>
> This is a variation of FORM authentication and closely related to ELY-508.
> The scenario would be prompt for a username, then prompt for a password and if the password is valid and the account supports OTP prompt for the OTP.
> The mechanism may also be responsible for sending the OTP but that is probably a side topic.
> I have raised this in terms of being a HTTP mechanism but the main point we need to ensure is covered is the requirements about identifying what checks are required for a specific user and tracking they are all complete.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 8 months