[JBoss JIRA] (ELY-1455) DB query seen for each request using programatic authentication
by Darran Lofthouse (Jira)
[ https://issues.jboss.org/browse/ELY-1455?page=com.atlassian.jira.plugin.s... ]
Darran Lofthouse updated ELY-1455:
----------------------------------
Fix Version/s: (was: 1.8.0.CR1)
> DB query seen for each request using programatic authentication
> ----------------------------------------------------------------
>
> Key: ELY-1455
> URL: https://issues.jboss.org/browse/ELY-1455
> Project: WildFly Elytron
> Issue Type: Bug
> Components: Authentication Mechanisms
> Affects Versions: 1.2.0.Beta10
> Reporter: Martin Choma
> Priority: Critical
> Attachments: elytron-bug.zip, server.log, standalone-full-ha.xml
>
>
> User is complaining, that DB is accessed on each request.
> Jdbc-realm + FORM authentication
> {noformat}
> <jdbc-realm name="myappRealm">
> <principal-query sql="SELECT r.role, u.password FROM user u join user_role_auth r on r.email = u.email where u.email=?" data-source="myds">
> <attribute-mapping>
> <attribute to="Roles" index="1"/>
> </attribute-mapping>
> <simple-digest-mapper password-index="2"/>
> </principal-query>
> </jdbc-realm>
> {noformat}
> {noformat}
> 2017-11-30 09:31:04,049 TRACE [org.wildfly.security] (default task-124) Principal assigning: [alberto(a)myapp.com], pre-realm rewritten: [alberto(a)myapp.com], realm name: [wmtRealm], post-realm rewritten: [alberto(a)myapp.com], realm rewritten: [alberto(a)myapp.com]
> 2017-11-30 09:31:04,049 TRACE [org.wildfly.security] (default task-124) Executing principalQuery select password from user where email = ? with value alberto(a)myapp.com
> 2017-11-30 09:31:04,051 TRACE [org.wildfly.security] (default task-124) Executing principalQuery select role, 'Roles' from user_role_auth where email = ? with value alberto(a)myapp.com
> 2017-11-30 09:31:04,052 TRACE [org.wildfly.security] (default task-124) Executing principalQuery select password from user where email = ? with value alberto(a)myapp.com
> 2017-11-30 09:31:04,053 TRACE [org.wildfly.security] (default task-124) Role mapping: principal [alberto(a)myapp.com] -> decoded roles [Administrator] -> realm mapped roles [Administrator] -> domain mapped roles [Administrator]
> 2017-11-30 09:31:04,053 TRACE [org.wildfly.security] (default task-124) Authorizing principal alberto(a)myapp.com.
> 2017-11-30 09:31:04,053 TRACE [org.wildfly.security] (default task-124) Authorizing against the following attributes: [roles] => [Administrator]
> 2017-11-30 09:31:04,053 TRACE [org.wildfly.security] (default task-124) Permission mapping: identity [alberto(a)myapp.com] with roles [Administrator] implies ("org.wildfly.security.auth.permission.LoginPermission" "") = true
> 2017-11-30 09:31:04,053 TRACE [org.wildfly.security] (default task-124) Authorization succeed
> 2017-11-30 09:31:04,053 TRACE [org.wildfly.security] (default task-124) Role mapping: principal [alberto(a)myapp.com] -> decoded roles [Administrator] -> realm mapped roles [Administrator] -> domain mapped roles [Administrator]
> 2017-11-30 09:31:07,017 TRACE [org.wildfly.security] (default task-125) Principal assigning: [alberto(a)myapp.com], pre-realm rewritten: [alberto(a)myapp.com], realm name: [wmtRealm], post-realm rewritten: [alberto(a)myapp.com], realm rewritten: [alberto(a)myapp.com]
> 2017-11-30 09:31:07,018 TRACE [org.wildfly.security] (default task-125) Executing principalQuery select password from user where email = ? with value alberto(a)myapp.com
> 2017-11-30 09:31:07,019 TRACE [org.wildfly.security] (default task-125) Executing principalQuery select role, 'Roles' from user_role_auth where email = ? with value alberto(a)myapp.com
> 2017-11-30 09:31:07,021 TRACE [org.wildfly.security] (default task-125) Executing principalQuery select password from user where email = ? with value alberto(a)myapp.com
> 2017-11-30 09:31:07,022 TRACE [org.wildfly.security] (default task-125) Role mapping: principal [alberto(a)myapp.com] -> decoded roles [Administrator] -> realm mapped roles [Administrator] -> domain mapped roles [Administrator]
> 2017-11-30 09:31:07,022 TRACE [org.wildfly.security] (default task-125) Authorizing principal alberto(a)myapp.com.
> 2017-11-30 09:31:07,023 TRACE [org.wildfly.security] (default task-125) Authorizing against the following attributes: [roles] => [Administrator]
> 2017-11-30 09:31:07,023 TRACE [org.wildfly.security] (default task-125) Permission mapping: identity [alberto(a)myapp.com] with roles [Administrator] implies ("org.wildfly.security.auth.permission.LoginPermission" "") = true
> 2017-11-30 09:31:07,023 TRACE [org.wildfly.security] (default task-125) Authorization succeed
> 2017-11-30 09:31:07,023 TRACE [org.wildfly.security] (default task-125) Role mapping: principal [alberto(a)myapp.com] -> decoded roles [Administrator] -> realm mapped roles [Administrator] -> domain mapped roles [Administrator]
> {noformat}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 10 months
[JBoss JIRA] (WFLY-8431) Race conditions in JASPIC registration code
by Darran Lofthouse (Jira)
[ https://issues.jboss.org/browse/WFLY-8431?page=com.atlassian.jira.plugin.... ]
Darran Lofthouse commented on WFLY-8431:
----------------------------------------
That PR currently has a merge conflict, if it is cleaned up we can review that one independently.
> Race conditions in JASPIC registration code
> -------------------------------------------
>
> Key: WFLY-8431
> URL: https://issues.jboss.org/browse/WFLY-8431
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 10.1.0.Final
> Environment: Centos 7 x86_64, with the included Java 8 environment
> Reporter: István Tóth
> Assignee: Darran Lofthouse
> Priority: Major
> Attachments: GetFactoryTestCase.java
>
>
> javax.security.auth.message.config.AuthConfigFactory and
> org.jboss.security.auth.message.config.JBossAuthConfigFactory
> have race conditions.
> 1. javax.security.auth.message.config.AuthConfigFactory#getFactory() has a race condition. The checking and creation of the _factory object is not atomic.
> I think the best and simplest solution would be to simply make the getFactory() method synchronized. (The same method in the Glassfish implmentation is synchronized)
> 2. The keyTo*Map fields of the org.jboss.security.auth.message.config.JBossAuthConfigFactory are not thread safe.
> Nearly all methods of this class manipulate these, without any synchronization.
> In this case I believe that changing those from HashMaps to ConcurrentHashMaps should be enough to avoid the worst of the races, while incurring a negligible performance penalty.
> The methods that modify the maps should also be made synchronized, or rewritten to use the
> atomic ConcurrentHashMaps operations.
> A possible workaround is to add a synchronized(AuthConfigFactory.class) block around the JASPIC initialization code, where the JBossAuthConfigFactory methods are called. Of course this only works if every webapp on the server can be modified this way.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 10 months
[JBoss JIRA] (WFLY-8431) Race conditions in JASPIC registration code
by István Tóth (Jira)
[ https://issues.jboss.org/browse/WFLY-8431?page=com.atlassian.jira.plugin.... ]
István Tóth commented on WFLY-8431:
-----------------------------------
Actually, I had two PRs in this ticket.
the fix for the more critical JBossAuthConfigFactory synchronization bug (at least this the bug that directly hits my code) is still not merged.
https://github.com/jboss/jboss-jaspi-api_spec/pull/4
Would you like me to update the PR to the trunk version?
> Race conditions in JASPIC registration code
> -------------------------------------------
>
> Key: WFLY-8431
> URL: https://issues.jboss.org/browse/WFLY-8431
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 10.1.0.Final
> Environment: Centos 7 x86_64, with the included Java 8 environment
> Reporter: István Tóth
> Assignee: Darran Lofthouse
> Priority: Major
> Attachments: GetFactoryTestCase.java
>
>
> javax.security.auth.message.config.AuthConfigFactory and
> org.jboss.security.auth.message.config.JBossAuthConfigFactory
> have race conditions.
> 1. javax.security.auth.message.config.AuthConfigFactory#getFactory() has a race condition. The checking and creation of the _factory object is not atomic.
> I think the best and simplest solution would be to simply make the getFactory() method synchronized. (The same method in the Glassfish implmentation is synchronized)
> 2. The keyTo*Map fields of the org.jboss.security.auth.message.config.JBossAuthConfigFactory are not thread safe.
> Nearly all methods of this class manipulate these, without any synchronization.
> In this case I believe that changing those from HashMaps to ConcurrentHashMaps should be enough to avoid the worst of the races, while incurring a negligible performance penalty.
> The methods that modify the maps should also be made synchronized, or rewritten to use the
> atomic ConcurrentHashMaps operations.
> A possible workaround is to add a synchronized(AuthConfigFactory.class) block around the JASPIC initialization code, where the JBossAuthConfigFactory methods are called. Of course this only works if every webapp on the server can be modified this way.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 10 months
[JBoss JIRA] (ELY-1617) Support SSL Certificate revocation using OCSP
by Darran Lofthouse (Jira)
[ https://issues.jboss.org/browse/ELY-1617?page=com.atlassian.jira.plugin.s... ]
Darran Lofthouse updated ELY-1617:
----------------------------------
Fix Version/s: 1.8.0.CR1
> Support SSL Certificate revocation using OCSP
> ---------------------------------------------
>
> Key: ELY-1617
> URL: https://issues.jboss.org/browse/ELY-1617
> Project: WildFly Elytron
> Issue Type: Task
> Components: SSL
> Affects Versions: 1.4.0.Final
> Reporter: Jan Kalina
> Assignee: Martin Mazanek
> Priority: Critical
> Fix For: 1.8.0.CR1
>
>
> - Provide undertow's client certificate revocation capability when undertow is used as a load balancer using OCSP.
> (CRL capability is provided in the earlier release as part of Elytron SSL Consolidation effort that this JIRA is cloned from)
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 10 months
[JBoss JIRA] (WFLY-6925) vault-tool adds invalid character to "ENC_FILE_DIR"
by Darran Lofthouse (Jira)
[ https://issues.jboss.org/browse/WFLY-6925?page=com.atlassian.jira.plugin.... ]
Darran Lofthouse resolved WFLY-6925.
------------------------------------
Assignee: Darran Lofthouse
Resolution: Won't Do
Marking as 'Won't Fix' as this is in relation to PicketBox which is deprecated.
> vault-tool adds invalid character to "ENC_FILE_DIR"
> ---------------------------------------------------
>
> Key: WFLY-6925
> URL: https://issues.jboss.org/browse/WFLY-6925
> Project: WildFly
> Issue Type: Feature Request
> Components: Security
> Affects Versions: 10.0.0.Final
> Reporter: Krashan Brahmanjara
> Assignee: Darran Lofthouse
> Priority: Trivial
>
> vault-tool executed on Windows adds invalid character to "ENC_FILE_DIR"
> for example this
> {code:java}
> <vault-option name="ENC_FILE_DIR" value="./vault\"/>
> {code}
> instead
> {code:java}
> <vault-option name="ENC_FILE_DIR" value="./vault/"/>
> {code}
> Second code also works on Windows and can be easily used on linux.
> Test command:
> vault.bat --keystore key.store --keystore-password abc123 --alias Vault --vault-block ws --attribute ws-user1 --sec-attr passwd --enc-dir ./vault --iteration 95 --salt ABCD1234
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 10 months
[JBoss JIRA] (WFLY-6881) User with password which contains chinese chars isn't able to log in to AD (on Windows).
by Darran Lofthouse (Jira)
[ https://issues.jboss.org/browse/WFLY-6881?page=com.atlassian.jira.plugin.... ]
Darran Lofthouse resolved WFLY-6881.
------------------------------------
Assignee: Darran Lofthouse
Resolution: Won't Fix
Marking as 'Won't Fix' as this is in relation to PicketBox which is deprecated.
> User with password which contains chinese chars isn't able to log in to AD (on Windows).
> ----------------------------------------------------------------------------------------
>
> Key: WFLY-6881
> URL: https://issues.jboss.org/browse/WFLY-6881
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Reporter: Hynek Švábek
> Assignee: Darran Lofthouse
> Priority: Minor
>
> We have a problem log in to AD on Windows. When user has password with chinese chars he cannot log in.
> My observations:
> I found out this: If I create AD entries from linux and update testsuite for using this entries (not creating own) then it is ok.
> I wasn't able to find out where is the exact problem. In my opinion there is some problem with creating AD user password on windows.
> Workaround:
> Creating AD data in other way.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 10 months