[JBoss JIRA] (ELY-1455) DB query seen for each request using FORM mechanism.
by Alberto Gori (JIRA)
[ https://issues.jboss.org/browse/ELY-1455?page=com.atlassian.jira.plugin.s... ]
Alberto Gori commented on ELY-1455:
-----------------------------------
Thanks for explanation. I am not sure I understood it completely.
Is it incorrect to declare a FORM authentication and use programmatic API instead? If so, what am I supposed to declare in auth-method tag in web.xml if I want to stick to programmatic API?
Or you were saying that this configuration is hitting a bug in elytron/wildfly?
Anyway, I think I'll go for option 2 (if FORM + API is ok).
Also, are these bugs related to SSO (that is not working at all)?
> DB query seen for each request using FORM mechanism.
> -----------------------------------------------------
>
> 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
> Assignee: Darran Lofthouse
> Fix For: 1.2.0.Beta11
>
> 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.5.0#75005)
8 years, 7 months
[JBoss JIRA] (WFCORE-3442) CLI can't reload if authentication configuration changed
by Jean-Francois Denise (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3442?page=com.atlassian.jira.plugi... ]
Jean-Francois Denise updated WFCORE-3442:
-----------------------------------------
Git Pull Request: https://github.com/wildfly/wildfly-core/pull/2971
> CLI can't reload if authentication configuration changed
> --------------------------------------------------------
>
> Key: WFCORE-3442
> URL: https://issues.jboss.org/browse/WFCORE-3442
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI
> Reporter: Jean-Francois Denise
> Assignee: Jean-Francois Denise
>
> The context:
> - Legacy ManagementRealm, no local-auth enabled, only users located properties file.
> - SASL authentication factory, digest with FooRealm, userName/password in other properties file
> The http management interface
> - Reference ManagementRealm and upgrade references SAL factory.
> From CLI:
> 1) User connects using credentials required for FooRealm
> 2) User disables SASL authentication : /core-service=management/management-interface=http-interface:write-attribute(name=http-upgrade.sasl-authentication-factory,value=undefined
> 3) User reloads ==> Connection fails.
> The user should be prompted for ManagementRealm credentials (if the current ones are not valid in the context of this realm).
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 7 months
[JBoss JIRA] (ELY-283) Investigate Elytron and gssproxy interoperability
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/ELY-283?page=com.atlassian.jira.plugin.sy... ]
Jan Kalina edited comment on ELY-283 at 12/6/17 5:32 PM:
---------------------------------------------------------
Currently it look gssproxy is providing credential correctly (with no error - major=0, minor=0 - by debug of gssproxy), but into java GSSContext arrive GSS_S_FAILURE - looks like raised somewhere on the way between gssproxy and JDK - have to investigate deeper...
{code}
[GSSLibStub_acquireCred]
[GSSLibStub_acquireCred] pName=140518513672464, usage=2
[GSSLibStub_acquireCred] pCred=0
[GSSLibStub_acquireCred] Status major/minor = d0000/69206038
c/r/s = 0/13/0
{code}
{code}
major = d0000 = 0 / 13 / 0
Calling Error = 0
Routine Error = 13 = GSS_S_FAILURE = Miscellaneous failure (see text)
Supplementary Status Bits = 0
minor = 69206038 (dec) = 04200016 (hex)
{code}
was (Author: honza889):
Currently it look gssproxy is providing credential correctly (with no error - major=0, minor=0 - by debug of gssproxy), but into java GSSContext arrive GSS_S_FAILURE - looks like raised somewhere on the way between gssproxy and JDK - have to investigate deeper...
{code}
[GSSLibStub_acquireCred]
[GSSLibStub_acquireCred] pName=140518513672464, usage=2
[GSSLibStub_acquireCred] pCred=0
[GSSLibStub_acquireCred] Status major/minor = d0000/69206038
c/r/s = 0/13/0
{code}
{code}
major = d0000 = 0 / 13 / 0
Calling Error = 0
Routine Error = 13 = GSS_S_FAILURE = Miscellaneous failure (see text)
Supplementary Status Bits = 0
minor = 69206038 (dec)
{code}
> Investigate Elytron and gssproxy interoperability
> -------------------------------------------------
>
> Key: ELY-283
> URL: https://issues.jboss.org/browse/ELY-283
> Project: WildFly Elytron
> Issue Type: Task
> Components: SASL
> Reporter: Peter Skopek
> Assignee: Jan Kalina
> Fix For: 2.0.0.Alpha1
>
>
> Investigate Elytron and gssproxy interoperability.
> https://fedorahosted.org/gss-proxy/
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 7 months
[JBoss JIRA] (ELY-283) Investigate Elytron and gssproxy interoperability
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/ELY-283?page=com.atlassian.jira.plugin.sy... ]
Jan Kalina commented on ELY-283:
--------------------------------
Currently it look gssproxy is providing credential correctly (with no error - major=0, minor=0 - by debug of gssproxy), but into java GSSContext arrive GSS_S_FAILURE - looks like raised somewhere on the way between gssproxy and JDK - have to investigate deeper...
{code}
[GSSLibStub_acquireCred]
[GSSLibStub_acquireCred] pName=140518513672464, usage=2
[GSSLibStub_acquireCred] pCred=0
[GSSLibStub_acquireCred] Status major/minor = d0000/69206038
c/r/s = 0/13/0
{code}
{code}
major = d0000 = 0 / 13 / 0
Calling Error = 0
Routine Error = 13 = GSS_S_FAILURE = Miscellaneous failure (see text)
Supplementary Status Bits = 0
minor = 69206038 (dec)
{code}
> Investigate Elytron and gssproxy interoperability
> -------------------------------------------------
>
> Key: ELY-283
> URL: https://issues.jboss.org/browse/ELY-283
> Project: WildFly Elytron
> Issue Type: Task
> Components: SASL
> Reporter: Peter Skopek
> Assignee: Jan Kalina
> Fix For: 2.0.0.Alpha1
>
>
> Investigate Elytron and gssproxy interoperability.
> https://fedorahosted.org/gss-proxy/
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 7 months