[Red Hat JIRA] (ELY-2074) SSO from FORM authentication required a distributed session
by Darran Lofthouse (Jira)
[ https://issues.redhat.com/browse/ELY-2074?page=com.atlassian.jira.plugin.... ]
Darran Lofthouse updated ELY-2074:
----------------------------------
Description:
Presently SSO only works on failover if also have a distributed HTTP session.
The SSO support is supposed to be operating independently of the session otherwise we should have just used the session to replicate the identity. I suspect that when we attempt to restore the identity we check if we have a session scope but as it does not exist we skip attempting the restoration, we should be open to restoration being possible without a session.
Overall however it feels like this approach will require some clean up which may be needed for ELY-1626 - instead of the current approach which intercepts session access and converts to SSO we may be better making SSO a real scope or something similar so mechanisms can interact directly with it. The approach today where we wrap the scope access and intercept the calls means mechanisms can easily make invalid assumptions about scope availability such as in this case.
The following TRACE logging shows a successful failover where a web application is marked as being distributed:
{code:java}
2021-01-26 11:01:34,120 TRACE [org.wildfly.security.http.servlet] (default task-1) Created ServletSecurityContextImpl enableJapi=true, integratedJaspi=true, applicationContext=default-host /simple-webapp
2021-01-26 11:01:34,121 TRACE [org.wildfly.security.http.servlet] (default task-1) No AuthConfigProvider for layer=HttpServlet, appContext=default-host /simple-webapp
2021-01-26 11:01:34,121 TRACE [org.wildfly.security.http.servlet] (default task-1) JASPIC Unavailable, using HTTP authentication.
2021-01-26 11:01:34,158 TRACE [org.wildfly.security] (default task-1) No CachedIdentity to restore.
2021-01-26 11:01:34,158 TRACE [org.wildfly.security] (default task-1) Created HttpServerAuthenticationMechanism [org.wildfly.security.auth.server.SecurityIdentityServerMechanismFactory$1@4b6842ff] for mechanism [FORM]
2021-01-26 11:01:34,160 TRACE [org.wildfly.security] (default task-1) Handling SocketAddressCallback
2021-01-26 11:01:34,160 TRACE [org.wildfly.security] (default task-1) Handling MechanismInformationCallback type='HTTP' name='FORM' host-name='localhost' protocol='http'
2021-01-26 11:01:34,160 TRACE [org.wildfly.security.http.form] (default task-1) Trying to re-authenticate session 3t7EGcnmInMeUYH3-thjyQpTyOanRdoX3Dm-BcS6. Request URI: [http://localhost:8080/simple-webapp/secured], Context path: [/simple-webapp]
2021-01-26 11:01:34,160 TRACE [org.wildfly.security] (default task-1) Principal assigning: [alice], pre-realm rewritten: [alice], realm name: [example-realm], post-realm rewritten: [alice], realm rewritten: [alice]
2021-01-26 11:01:34,165 TRACE [org.wildfly.security] (default task-1) Role mapping: principal [alice] -> decoded roles [Users, user] -> domain decoded roles [] -> realm mapped roles [Users, user] -> domain mapped roles [Users, user]
2021-01-26 11:01:34,166 TRACE [org.wildfly.security] (default task-1) Authorizing principal alice.
2021-01-26 11:01:34,166 TRACE [org.wildfly.security] (default task-1) Authorizing against the following attributes: [groups] => [user, Users]
2021-01-26 11:01:34,166 TRACE [org.wildfly.security] (default task-1) Authorizing against the following runtime attributes: [Source-Address] => [127.0.0.1]
2021-01-26 11:01:34,166 TRACE [org.wildfly.security] (default task-1) Permission mapping: identity [alice] with roles [Users, user] implies ("org.wildfly.security.auth.permission.LoginPermission" "") = true
2021-01-26 11:01:34,166 TRACE [org.wildfly.security] (default task-1) Authorization succeed
2021-01-26 11:01:34,166 TRACE [org.wildfly.security] (default task-1) Handling CachedIdentityAuthorizeCallback: principal = alice authorizedIdentity = SecurityIdentity{principal=alice, securityDomain=org.wildfly.security.auth.server.SecurityDomain@61f54c5f, authorizationIdentity=EMPTY, realmInfo=RealmInfo{name='example-realm', securityRealm=org.wildfly.security.auth.realm.FileSystemSecurityRealm@78079856}, creationTime=2021-01-26T11:01:34.165503Z}
2021-01-26 11:01:34,167 TRACE [org.wildfly.security] (default task-1) Handling AuthenticationCompleteCallback: succeed
2021-01-26 11:01:34,167 TRACE [org.wildfly.security] (default task-1) Handling SecurityIdentityCallback: identity = SecurityIdentity{principal=alice, securityDomain=org.wildfly.security.auth.server.SecurityDomain@61f54c5f, authorizationIdentity=EMPTY, realmInfo=RealmInfo{name='example-realm', securityRealm=org.wildfly.security.auth.realm.FileSystemSecurityRealm@78079856}, creationTime=2021-01-26T11:01:34.165503Z}
2021-01-26 11:01:34,168 TRACE [org.wildfly.security] (default task-1) Role mapping: principal [alice] -> decoded roles [Users, user] -> domain decoded roles [] -> realm mapped roles [Users, user] -> domain mapped roles [Users, user] {code}
Where the web application is not distributed the following is logged instead:
{code:java}
2021-01-26 11:26:14,189 INFO [org.infinispan.CLUSTER] (thread-10,ejb,nodea) ISPN100001: Node nodeb left the cluster
2021-01-26 11:26:59,400 TRACE [org.wildfly.security.http.servlet] (default task-1) Created ServletSecurityContextImpl enableJapi=true, integratedJaspi=true, applicationContext=default-host /simple-webapp
2021-01-26 11:26:59,400 TRACE [org.wildfly.security.http.servlet] (default task-1) No AuthConfigProvider for layer=HttpServlet, appContext=default-host /simple-webapp
2021-01-26 11:26:59,400 TRACE [org.wildfly.security.http.servlet] (default task-1) JASPIC Unavailable, using HTTP authentication.
2021-01-26 11:26:59,402 TRACE [org.wildfly.security] (default task-1) No CachedIdentity to restore.
2021-01-26 11:26:59,402 TRACE [org.wildfly.security] (default task-1) Created HttpServerAuthenticationMechanism [org.wildfly.security.auth.server.SecurityIdentityServerMechanismFactory$1@71dc2149] for mechanism [FORM]
2021-01-26 11:26:59,404 TRACE [org.wildfly.security] (default task-1) Handling SocketAddressCallback
2021-01-26 11:26:59,404 TRACE [org.wildfly.security] (default task-1) Handling MechanismInformationCallback type='HTTP' name='FORM' host-name='localhost' protocol='http'
2021-01-26 11:26:59,404 TRACE [org.wildfly.security.http.form] (default task-1) Trying to re-authenticate. There is no session attached to the following request. Request URI: [http://localhost:8080/simple-webapp/secured], Context path: [/simple-webapp]
2021-01-26 11:26:59,404 TRACE [org.wildfly.security] (default task-1) Handling CachedIdentityAuthorizeCallback: principal = null authorizedIdentity = null {code}
was:
Presently SSO only works on failover if also have a distributed HTTP session.
The SSO support is supposed to be operating independently of the session otherwise we should have just used the session to replicate the identity. I suspect that when we attempt to restore the identity we check if we have a session scope but as it does not exist we skip attempting the restoration, we should be open to restoration being possible without a session.
Overall however it feels like this approach will require some clean up which may be needed for ELY-1626 - instead of the current approach which intercepts session access and converts to SSO we may be better making SSO a real scope or something similar so mechanisms can interact directly with it. The approach today where we wrap the scope access and intercept the calls means mechanisms can easily make invalid assumptions about scope availability such as in this case.
The following TRACE logging shows a successful failover where a web application is marked as being distributed:
{code:java}
2021-01-26 11:01:34,120 TRACE [org.wildfly.security.http.servlet] (default task-1) Created ServletSecurityContextImpl enableJapi=true, integratedJaspi=true, applicationContext=default-host /simple-webapp
2021-01-26 11:01:34,121 TRACE [org.wildfly.security.http.servlet] (default task-1) No AuthConfigProvider for layer=HttpServlet, appContext=default-host /simple-webapp
2021-01-26 11:01:34,121 TRACE [org.wildfly.security.http.servlet] (default task-1) JASPIC Unavailable, using HTTP authentication.
2021-01-26 11:01:34,158 TRACE [org.wildfly.security] (default task-1) No CachedIdentity to restore.
2021-01-26 11:01:34,158 TRACE [org.wildfly.security] (default task-1) Created HttpServerAuthenticationMechanism [org.wildfly.security.auth.server.SecurityIdentityServerMechanismFactory$1@4b6842ff] for mechanism [FORM]
2021-01-26 11:01:34,160 TRACE [org.wildfly.security] (default task-1) Handling SocketAddressCallback
2021-01-26 11:01:34,160 TRACE [org.wildfly.security] (default task-1) Handling MechanismInformationCallback type='HTTP' name='FORM' host-name='localhost' protocol='http'
2021-01-26 11:01:34,160 TRACE [org.wildfly.security.http.form] (default task-1) Trying to re-authenticate session 3t7EGcnmInMeUYH3-thjyQpTyOanRdoX3Dm-BcS6. Request URI: [http://localhost:8080/simple-webapp/secured], Context path: [/simple-webapp]
2021-01-26 11:01:34,160 TRACE [org.wildfly.security] (default task-1) Principal assigning: [alice], pre-realm rewritten: [alice], realm name: [example-realm], post-realm rewritten: [alice], realm rewritten: [alice]
2021-01-26 11:01:34,165 TRACE [org.wildfly.security] (default task-1) Role mapping: principal [alice] -> decoded roles [Users, user] -> domain decoded roles [] -> realm mapped roles [Users, user] -> domain mapped roles [Users, user]
2021-01-26 11:01:34,166 TRACE [org.wildfly.security] (default task-1) Authorizing principal alice.
2021-01-26 11:01:34,166 TRACE [org.wildfly.security] (default task-1) Authorizing against the following attributes: [groups] => [user, Users]
2021-01-26 11:01:34,166 TRACE [org.wildfly.security] (default task-1) Authorizing against the following runtime attributes: [Source-Address] => [127.0.0.1]
2021-01-26 11:01:34,166 TRACE [org.wildfly.security] (default task-1) Permission mapping: identity [alice] with roles [Users, user] implies ("org.wildfly.security.auth.permission.LoginPermission" "") = true
2021-01-26 11:01:34,166 TRACE [org.wildfly.security] (default task-1) Authorization succeed
2021-01-26 11:01:34,166 TRACE [org.wildfly.security] (default task-1) Handling CachedIdentityAuthorizeCallback: principal = alice authorizedIdentity = SecurityIdentity{principal=alice, securityDomain=org.wildfly.security.auth.server.SecurityDomain@61f54c5f, authorizationIdentity=EMPTY, realmInfo=RealmInfo{name='example-realm', securityRealm=org.wildfly.security.auth.realm.FileSystemSecurityRealm@78079856}, creationTime=2021-01-26T11:01:34.165503Z}
2021-01-26 11:01:34,167 TRACE [org.wildfly.security] (default task-1) Handling AuthenticationCompleteCallback: succeed
2021-01-26 11:01:34,167 TRACE [org.wildfly.security] (default task-1) Handling SecurityIdentityCallback: identity = SecurityIdentity{principal=alice, securityDomain=org.wildfly.security.auth.server.SecurityDomain@61f54c5f, authorizationIdentity=EMPTY, realmInfo=RealmInfo{name='example-realm', securityRealm=org.wildfly.security.auth.realm.FileSystemSecurityRealm@78079856}, creationTime=2021-01-26T11:01:34.165503Z}
2021-01-26 11:01:34,168 TRACE [org.wildfly.security] (default task-1) Role mapping: principal [alice] -> decoded roles [Users, user] -> domain decoded roles [] -> realm mapped roles [Users, user] -> domain mapped roles [Users, user] {code}
> SSO from FORM authentication required a distributed session
> -----------------------------------------------------------
>
> Key: ELY-2074
> URL: https://issues.redhat.com/browse/ELY-2074
> Project: WildFly Elytron
> Issue Type: Bug
> Components: HTTP
> Affects Versions: 1.14.1.Final
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Priority: Major
> Fix For: 1.14.2.CR1
>
>
> Presently SSO only works on failover if also have a distributed HTTP session.
> The SSO support is supposed to be operating independently of the session otherwise we should have just used the session to replicate the identity. I suspect that when we attempt to restore the identity we check if we have a session scope but as it does not exist we skip attempting the restoration, we should be open to restoration being possible without a session.
> Overall however it feels like this approach will require some clean up which may be needed for ELY-1626 - instead of the current approach which intercepts session access and converts to SSO we may be better making SSO a real scope or something similar so mechanisms can interact directly with it. The approach today where we wrap the scope access and intercept the calls means mechanisms can easily make invalid assumptions about scope availability such as in this case.
> The following TRACE logging shows a successful failover where a web application is marked as being distributed:
> {code:java}
> 2021-01-26 11:01:34,120 TRACE [org.wildfly.security.http.servlet] (default task-1) Created ServletSecurityContextImpl enableJapi=true, integratedJaspi=true, applicationContext=default-host /simple-webapp
> 2021-01-26 11:01:34,121 TRACE [org.wildfly.security.http.servlet] (default task-1) No AuthConfigProvider for layer=HttpServlet, appContext=default-host /simple-webapp
> 2021-01-26 11:01:34,121 TRACE [org.wildfly.security.http.servlet] (default task-1) JASPIC Unavailable, using HTTP authentication.
> 2021-01-26 11:01:34,158 TRACE [org.wildfly.security] (default task-1) No CachedIdentity to restore.
> 2021-01-26 11:01:34,158 TRACE [org.wildfly.security] (default task-1) Created HttpServerAuthenticationMechanism [org.wildfly.security.auth.server.SecurityIdentityServerMechanismFactory$1@4b6842ff] for mechanism [FORM]
> 2021-01-26 11:01:34,160 TRACE [org.wildfly.security] (default task-1) Handling SocketAddressCallback
> 2021-01-26 11:01:34,160 TRACE [org.wildfly.security] (default task-1) Handling MechanismInformationCallback type='HTTP' name='FORM' host-name='localhost' protocol='http'
> 2021-01-26 11:01:34,160 TRACE [org.wildfly.security.http.form] (default task-1) Trying to re-authenticate session 3t7EGcnmInMeUYH3-thjyQpTyOanRdoX3Dm-BcS6. Request URI: [http://localhost:8080/simple-webapp/secured], Context path: [/simple-webapp]
> 2021-01-26 11:01:34,160 TRACE [org.wildfly.security] (default task-1) Principal assigning: [alice], pre-realm rewritten: [alice], realm name: [example-realm], post-realm rewritten: [alice], realm rewritten: [alice]
> 2021-01-26 11:01:34,165 TRACE [org.wildfly.security] (default task-1) Role mapping: principal [alice] -> decoded roles [Users, user] -> domain decoded roles [] -> realm mapped roles [Users, user] -> domain mapped roles [Users, user]
> 2021-01-26 11:01:34,166 TRACE [org.wildfly.security] (default task-1) Authorizing principal alice.
> 2021-01-26 11:01:34,166 TRACE [org.wildfly.security] (default task-1) Authorizing against the following attributes: [groups] => [user, Users]
> 2021-01-26 11:01:34,166 TRACE [org.wildfly.security] (default task-1) Authorizing against the following runtime attributes: [Source-Address] => [127.0.0.1]
> 2021-01-26 11:01:34,166 TRACE [org.wildfly.security] (default task-1) Permission mapping: identity [alice] with roles [Users, user] implies ("org.wildfly.security.auth.permission.LoginPermission" "") = true
> 2021-01-26 11:01:34,166 TRACE [org.wildfly.security] (default task-1) Authorization succeed
> 2021-01-26 11:01:34,166 TRACE [org.wildfly.security] (default task-1) Handling CachedIdentityAuthorizeCallback: principal = alice authorizedIdentity = SecurityIdentity{principal=alice, securityDomain=org.wildfly.security.auth.server.SecurityDomain@61f54c5f, authorizationIdentity=EMPTY, realmInfo=RealmInfo{name='example-realm', securityRealm=org.wildfly.security.auth.realm.FileSystemSecurityRealm@78079856}, creationTime=2021-01-26T11:01:34.165503Z}
> 2021-01-26 11:01:34,167 TRACE [org.wildfly.security] (default task-1) Handling AuthenticationCompleteCallback: succeed
> 2021-01-26 11:01:34,167 TRACE [org.wildfly.security] (default task-1) Handling SecurityIdentityCallback: identity = SecurityIdentity{principal=alice, securityDomain=org.wildfly.security.auth.server.SecurityDomain@61f54c5f, authorizationIdentity=EMPTY, realmInfo=RealmInfo{name='example-realm', securityRealm=org.wildfly.security.auth.realm.FileSystemSecurityRealm@78079856}, creationTime=2021-01-26T11:01:34.165503Z}
> 2021-01-26 11:01:34,168 TRACE [org.wildfly.security] (default task-1) Role mapping: principal [alice] -> decoded roles [Users, user] -> domain decoded roles [] -> realm mapped roles [Users, user] -> domain mapped roles [Users, user] {code}
>
> Where the web application is not distributed the following is logged instead:
> {code:java}
> 2021-01-26 11:26:14,189 INFO [org.infinispan.CLUSTER] (thread-10,ejb,nodea) ISPN100001: Node nodeb left the cluster
> 2021-01-26 11:26:59,400 TRACE [org.wildfly.security.http.servlet] (default task-1) Created ServletSecurityContextImpl enableJapi=true, integratedJaspi=true, applicationContext=default-host /simple-webapp
> 2021-01-26 11:26:59,400 TRACE [org.wildfly.security.http.servlet] (default task-1) No AuthConfigProvider for layer=HttpServlet, appContext=default-host /simple-webapp
> 2021-01-26 11:26:59,400 TRACE [org.wildfly.security.http.servlet] (default task-1) JASPIC Unavailable, using HTTP authentication.
> 2021-01-26 11:26:59,402 TRACE [org.wildfly.security] (default task-1) No CachedIdentity to restore.
> 2021-01-26 11:26:59,402 TRACE [org.wildfly.security] (default task-1) Created HttpServerAuthenticationMechanism [org.wildfly.security.auth.server.SecurityIdentityServerMechanismFactory$1@71dc2149] for mechanism [FORM]
> 2021-01-26 11:26:59,404 TRACE [org.wildfly.security] (default task-1) Handling SocketAddressCallback
> 2021-01-26 11:26:59,404 TRACE [org.wildfly.security] (default task-1) Handling MechanismInformationCallback type='HTTP' name='FORM' host-name='localhost' protocol='http'
> 2021-01-26 11:26:59,404 TRACE [org.wildfly.security.http.form] (default task-1) Trying to re-authenticate. There is no session attached to the following request. Request URI: [http://localhost:8080/simple-webapp/secured], Context path: [/simple-webapp]
> 2021-01-26 11:26:59,404 TRACE [org.wildfly.security] (default task-1) Handling CachedIdentityAuthorizeCallback: principal = null authorizedIdentity = null {code}
>
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
5 years, 2 months
[Red Hat JIRA] (ELY-2074) SSO from FORM authentication required a distributed session
by Darran Lofthouse (Jira)
[ https://issues.redhat.com/browse/ELY-2074?page=com.atlassian.jira.plugin.... ]
Darran Lofthouse updated ELY-2074:
----------------------------------
Description:
Presently SSO only works on failover if also have a distributed HTTP session.
The SSO support is supposed to be operating independently of the session otherwise we should have just used the session to replicate the identity. I suspect that when we attempt to restore the identity we check if we have a session scope but as it does not exist we skip attempting the restoration, we should be open to restoration being possible without a session.
Overall however it feels like this approach will require some clean up which may be needed for ELY-1626 - instead of the current approach which intercepts session access and converts to SSO we may be better making SSO a real scope or something similar so mechanisms can interact directly with it. The approach today where we wrap the scope access and intercept the calls means mechanisms can easily make invalid assumptions about scope availability such as in this case.
The following TRACE logging shows a successful failover where a web application is marked as being distributed:
{code:java}
2021-01-26 11:01:34,120 TRACE [org.wildfly.security.http.servlet] (default task-1) Created ServletSecurityContextImpl enableJapi=true, integratedJaspi=true, applicationContext=default-host /simple-webapp
2021-01-26 11:01:34,121 TRACE [org.wildfly.security.http.servlet] (default task-1) No AuthConfigProvider for layer=HttpServlet, appContext=default-host /simple-webapp
2021-01-26 11:01:34,121 TRACE [org.wildfly.security.http.servlet] (default task-1) JASPIC Unavailable, using HTTP authentication.
2021-01-26 11:01:34,158 TRACE [org.wildfly.security] (default task-1) No CachedIdentity to restore.
2021-01-26 11:01:34,158 TRACE [org.wildfly.security] (default task-1) Created HttpServerAuthenticationMechanism [org.wildfly.security.auth.server.SecurityIdentityServerMechanismFactory$1@4b6842ff] for mechanism [FORM]
2021-01-26 11:01:34,160 TRACE [org.wildfly.security] (default task-1) Handling SocketAddressCallback
2021-01-26 11:01:34,160 TRACE [org.wildfly.security] (default task-1) Handling MechanismInformationCallback type='HTTP' name='FORM' host-name='localhost' protocol='http'
2021-01-26 11:01:34,160 TRACE [org.wildfly.security.http.form] (default task-1) Trying to re-authenticate session 3t7EGcnmInMeUYH3-thjyQpTyOanRdoX3Dm-BcS6. Request URI: [http://localhost:8080/simple-webapp/secured], Context path: [/simple-webapp]
2021-01-26 11:01:34,160 TRACE [org.wildfly.security] (default task-1) Principal assigning: [alice], pre-realm rewritten: [alice], realm name: [example-realm], post-realm rewritten: [alice], realm rewritten: [alice]
2021-01-26 11:01:34,165 TRACE [org.wildfly.security] (default task-1) Role mapping: principal [alice] -> decoded roles [Users, user] -> domain decoded roles [] -> realm mapped roles [Users, user] -> domain mapped roles [Users, user]
2021-01-26 11:01:34,166 TRACE [org.wildfly.security] (default task-1) Authorizing principal alice.
2021-01-26 11:01:34,166 TRACE [org.wildfly.security] (default task-1) Authorizing against the following attributes: [groups] => [user, Users]
2021-01-26 11:01:34,166 TRACE [org.wildfly.security] (default task-1) Authorizing against the following runtime attributes: [Source-Address] => [127.0.0.1]
2021-01-26 11:01:34,166 TRACE [org.wildfly.security] (default task-1) Permission mapping: identity [alice] with roles [Users, user] implies ("org.wildfly.security.auth.permission.LoginPermission" "") = true
2021-01-26 11:01:34,166 TRACE [org.wildfly.security] (default task-1) Authorization succeed
2021-01-26 11:01:34,166 TRACE [org.wildfly.security] (default task-1) Handling CachedIdentityAuthorizeCallback: principal = alice authorizedIdentity = SecurityIdentity{principal=alice, securityDomain=org.wildfly.security.auth.server.SecurityDomain@61f54c5f, authorizationIdentity=EMPTY, realmInfo=RealmInfo{name='example-realm', securityRealm=org.wildfly.security.auth.realm.FileSystemSecurityRealm@78079856}, creationTime=2021-01-26T11:01:34.165503Z}
2021-01-26 11:01:34,167 TRACE [org.wildfly.security] (default task-1) Handling AuthenticationCompleteCallback: succeed
2021-01-26 11:01:34,167 TRACE [org.wildfly.security] (default task-1) Handling SecurityIdentityCallback: identity = SecurityIdentity{principal=alice, securityDomain=org.wildfly.security.auth.server.SecurityDomain@61f54c5f, authorizationIdentity=EMPTY, realmInfo=RealmInfo{name='example-realm', securityRealm=org.wildfly.security.auth.realm.FileSystemSecurityRealm@78079856}, creationTime=2021-01-26T11:01:34.165503Z}
2021-01-26 11:01:34,168 TRACE [org.wildfly.security] (default task-1) Role mapping: principal [alice] -> decoded roles [Users, user] -> domain decoded roles [] -> realm mapped roles [Users, user] -> domain mapped roles [Users, user] {code}
was:
Presently SSO only works on failover if also have a distributed HTTP session.
The SSO support is supposed to be operating independently of the session otherwise we should have just used the session to replicate the identity. I suspect that when we attempt to restore the identity we check if we have a session scope but as it does not exist we skip attempting the restoration, we should be open to restoration being possible without a session.
Overall however it feels like this approach will require some clean up which may be needed for ELY-1626 - instead of the current approach which intercepts session access and converts to SSO we may be better making SSO a real scope or something similar so mechanisms can interact directly with it. The approach today where we wrap the scope access and intercept the calls means mechanisms can easily make invalid assumptions about scope availability such as in this case.
> SSO from FORM authentication required a distributed session
> -----------------------------------------------------------
>
> Key: ELY-2074
> URL: https://issues.redhat.com/browse/ELY-2074
> Project: WildFly Elytron
> Issue Type: Bug
> Components: HTTP
> Affects Versions: 1.14.1.Final
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Priority: Major
> Fix For: 1.14.2.CR1
>
>
> Presently SSO only works on failover if also have a distributed HTTP session.
> The SSO support is supposed to be operating independently of the session otherwise we should have just used the session to replicate the identity. I suspect that when we attempt to restore the identity we check if we have a session scope but as it does not exist we skip attempting the restoration, we should be open to restoration being possible without a session.
> Overall however it feels like this approach will require some clean up which may be needed for ELY-1626 - instead of the current approach which intercepts session access and converts to SSO we may be better making SSO a real scope or something similar so mechanisms can interact directly with it. The approach today where we wrap the scope access and intercept the calls means mechanisms can easily make invalid assumptions about scope availability such as in this case.
> The following TRACE logging shows a successful failover where a web application is marked as being distributed:
> {code:java}
> 2021-01-26 11:01:34,120 TRACE [org.wildfly.security.http.servlet] (default task-1) Created ServletSecurityContextImpl enableJapi=true, integratedJaspi=true, applicationContext=default-host /simple-webapp
> 2021-01-26 11:01:34,121 TRACE [org.wildfly.security.http.servlet] (default task-1) No AuthConfigProvider for layer=HttpServlet, appContext=default-host /simple-webapp
> 2021-01-26 11:01:34,121 TRACE [org.wildfly.security.http.servlet] (default task-1) JASPIC Unavailable, using HTTP authentication.
> 2021-01-26 11:01:34,158 TRACE [org.wildfly.security] (default task-1) No CachedIdentity to restore.
> 2021-01-26 11:01:34,158 TRACE [org.wildfly.security] (default task-1) Created HttpServerAuthenticationMechanism [org.wildfly.security.auth.server.SecurityIdentityServerMechanismFactory$1@4b6842ff] for mechanism [FORM]
> 2021-01-26 11:01:34,160 TRACE [org.wildfly.security] (default task-1) Handling SocketAddressCallback
> 2021-01-26 11:01:34,160 TRACE [org.wildfly.security] (default task-1) Handling MechanismInformationCallback type='HTTP' name='FORM' host-name='localhost' protocol='http'
> 2021-01-26 11:01:34,160 TRACE [org.wildfly.security.http.form] (default task-1) Trying to re-authenticate session 3t7EGcnmInMeUYH3-thjyQpTyOanRdoX3Dm-BcS6. Request URI: [http://localhost:8080/simple-webapp/secured], Context path: [/simple-webapp]
> 2021-01-26 11:01:34,160 TRACE [org.wildfly.security] (default task-1) Principal assigning: [alice], pre-realm rewritten: [alice], realm name: [example-realm], post-realm rewritten: [alice], realm rewritten: [alice]
> 2021-01-26 11:01:34,165 TRACE [org.wildfly.security] (default task-1) Role mapping: principal [alice] -> decoded roles [Users, user] -> domain decoded roles [] -> realm mapped roles [Users, user] -> domain mapped roles [Users, user]
> 2021-01-26 11:01:34,166 TRACE [org.wildfly.security] (default task-1) Authorizing principal alice.
> 2021-01-26 11:01:34,166 TRACE [org.wildfly.security] (default task-1) Authorizing against the following attributes: [groups] => [user, Users]
> 2021-01-26 11:01:34,166 TRACE [org.wildfly.security] (default task-1) Authorizing against the following runtime attributes: [Source-Address] => [127.0.0.1]
> 2021-01-26 11:01:34,166 TRACE [org.wildfly.security] (default task-1) Permission mapping: identity [alice] with roles [Users, user] implies ("org.wildfly.security.auth.permission.LoginPermission" "") = true
> 2021-01-26 11:01:34,166 TRACE [org.wildfly.security] (default task-1) Authorization succeed
> 2021-01-26 11:01:34,166 TRACE [org.wildfly.security] (default task-1) Handling CachedIdentityAuthorizeCallback: principal = alice authorizedIdentity = SecurityIdentity{principal=alice, securityDomain=org.wildfly.security.auth.server.SecurityDomain@61f54c5f, authorizationIdentity=EMPTY, realmInfo=RealmInfo{name='example-realm', securityRealm=org.wildfly.security.auth.realm.FileSystemSecurityRealm@78079856}, creationTime=2021-01-26T11:01:34.165503Z}
> 2021-01-26 11:01:34,167 TRACE [org.wildfly.security] (default task-1) Handling AuthenticationCompleteCallback: succeed
> 2021-01-26 11:01:34,167 TRACE [org.wildfly.security] (default task-1) Handling SecurityIdentityCallback: identity = SecurityIdentity{principal=alice, securityDomain=org.wildfly.security.auth.server.SecurityDomain@61f54c5f, authorizationIdentity=EMPTY, realmInfo=RealmInfo{name='example-realm', securityRealm=org.wildfly.security.auth.realm.FileSystemSecurityRealm@78079856}, creationTime=2021-01-26T11:01:34.165503Z}
> 2021-01-26 11:01:34,168 TRACE [org.wildfly.security] (default task-1) Role mapping: principal [alice] -> decoded roles [Users, user] -> domain decoded roles [] -> realm mapped roles [Users, user] -> domain mapped roles [Users, user] {code}
>
>
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
5 years, 2 months
[Red Hat JIRA] (ELY-2074) SSO from FORM authentication required a distributed session
by Darran Lofthouse (Jira)
Darran Lofthouse created ELY-2074:
-------------------------------------
Summary: SSO from FORM authentication required a distributed session
Key: ELY-2074
URL: https://issues.redhat.com/browse/ELY-2074
Project: WildFly Elytron
Issue Type: Bug
Components: HTTP
Affects Versions: 1.14.1.Final
Reporter: Darran Lofthouse
Assignee: Darran Lofthouse
Fix For: 1.14.2.CR1
Presently SSO only works on failover if also have a distributed HTTP session.
The SSO support is supposed to be operating independently of the session otherwise we should have just used the session to replicate the identity. I suspect that when we attempt to restore the identity we check if we have a session scope but as it does not exist we skip attempting the restoration, we should be open to restoration being possible without a session.
Overall however it feels like this approach will require some clean up which may be needed for ELY-1626 - instead of the current approach which intercepts session access and converts to SSO we may be better making SSO a real scope or something similar so mechanisms can interact directly with it. The approach today where we wrap the scope access and intercept the calls means mechanisms can easily make invalid assumptions about scope availability such as in this case.
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
5 years, 2 months
[Red Hat JIRA] (WFLY-14356) Infinispan heap-memory caches transcoding key/values unnecessarily
by Ryan Emerson (Jira)
Ryan Emerson created WFLY-14356:
-----------------------------------
Summary: Infinispan heap-memory caches transcoding key/values unnecessarily
Key: WFLY-14356
URL: https://issues.redhat.com/browse/WFLY-14356
Project: WildFly
Issue Type: Bug
Components: Clustering
Affects Versions: 21.0.2.Final
Reporter: Ryan Emerson
Assignee: Paul Ferraro
For local "heap-memory" caches, each key/value stored are being converted to a byte[] unnecessarily.
The reason that this conversion is taking place, is due to a combination of 1) the key/value encoding type of Wildfly's "heap-memory" caches not being explicitly configured. 2) Wildfly using Infinispan in server mode by configuring [1]. This causes Infinispan `StorageConfigurationManager`[2] to configure the storage media type as `application/unknown`, which results in the `application/x-java-object` key/values being converted to byte[] on every put operation.
The simplest solution is to update the "heap-memory" caches to explicitly configure the encoding as `application/x-java-object`. This will be mandatory in future versions anyway, as the `application/unknown` type has been deprecated.
[1] https://github.com/wildfly/wildfly/blob/2bed1cae0c56d697ee0fc80b7f3390...
[2] https://github.com/infinispan/infinispan/blob/0454c2368ad8365c93042a9e...
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
5 years, 2 months
[Red Hat JIRA] (DROOLS-5512) Unsaved changes dialog for a Test Scenario executed right after creation
by Jozef Marko (Jira)
[ https://issues.redhat.com/browse/DROOLS-5512?page=com.atlassian.jira.plug... ]
Jozef Marko updated DROOLS-5512:
--------------------------------
Fix Version/s: 7.49.0.Final
> Unsaved changes dialog for a Test Scenario executed right after creation
> ------------------------------------------------------------------------
>
> Key: DROOLS-5512
> URL: https://issues.redhat.com/browse/DROOLS-5512
> Project: Drools
> Issue Type: Bug
> Components: Scenario Simulation and Testing
> Affects Versions: 7.41.0.Final
> Reporter: Jan Stastny
> Assignee: Yeser Amer
> Priority: Major
> Labels: drools-tools
> Fix For: 7.49.0.Final
>
>
> There is once again an Unsaved Changes dialog presented to user even though no changes has been made.
> This time it is when user creates Test Scenario, fills in facts and values, saves and executes the test scenario right away. When clicking save and trying to close again it does not appear again. There us not commit in niogit connected with the second save.
> When user closes and reopens editor between save and run, all works fine.
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
5 years, 2 months
[Red Hat JIRA] (AG-154) Connection leak when DB connection closed during transaction rollback
by Wojciech Kopciewicz (Jira)
[ https://issues.redhat.com/browse/AG-154?page=com.atlassian.jira.plugin.sy... ]
Wojciech Kopciewicz commented on AG-154:
----------------------------------------
Hi [~lbarreiro],
Any updates on this? This starts to become blocking for us.
> Connection leak when DB connection closed during transaction rollback
> ---------------------------------------------------------------------
>
> Key: AG-154
> URL: https://issues.redhat.com/browse/AG-154
> Project: Agroal
> Issue Type: Bug
> Components: narayana, pool
> Affects Versions: 1.9
> Reporter: Wojciech Kopciewicz
> Assignee: Luis Barreiro
> Priority: Major
>
> We are using Quarkus 1.9.2 with Hibernate and Agroal to access PostgreSQL DB.
> It looks like Agroal is leaking connections when connection is closed (somewhere) on the server side during transaction rollback.
> The following log was observed:
> Error trying to transactionRollback local transaction: This connection has been closed.
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
5 years, 2 months
[Red Hat JIRA] (WFLY-14006) Consider having the Extension implementation for extensions with deprecated subsystems register themselves as such
by Yeray Borges Santana (Jira)
[ https://issues.redhat.com/browse/WFLY-14006?page=com.atlassian.jira.plugi... ]
Yeray Borges Santana reassigned WFLY-14006:
-------------------------------------------
Assignee: Yeray Borges Santana
> Consider having the Extension implementation for extensions with deprecated subsystems register themselves as such
> ------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-14006
> URL: https://issues.redhat.com/browse/WFLY-14006
> Project: WildFly
> Issue Type: Task
> Components: Management
> Reporter: Brian Stansberry
> Assignee: Yeray Borges Santana
> Priority: Minor
>
> ExtensionContext.registerSubsystem has an overloaded variant that takes a boolean 'deprecated' parameter. We never use it.
> For deprecated subsystems we *perhaps* should.
> I think most of our deprecated subsystems are using the SimpleResourceDefinition.setDeprecated API to trigger deprecation logging if the subsystem is actually added. So this extension call really is just for the case where the extension is included in the config but is not used for adding a subsystem. That's kind of a corner case so it's a valid question whether we want to add this setting and end up writing *two* messages to the log.
> So this issue is to track at least considering it.
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
5 years, 2 months
[Red Hat JIRA] (WFCORE-5247) IllegalArgumentException and CLI crash with read-attribute in /system-property
by Jean Francois Denise (Jira)
[ https://issues.redhat.com/browse/WFCORE-5247?page=com.atlassian.jira.plug... ]
Jean Francois Denise commented on WFCORE-5247:
----------------------------------------------
[~soul2zimate], thank-you very much for sharing your findings, [~parsharma] will surely benefit from it!
> IllegalArgumentException and CLI crash with read-attribute in /system-property
> ------------------------------------------------------------------------------
>
> Key: WFCORE-5247
> URL: https://issues.redhat.com/browse/WFCORE-5247
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI
> Affects Versions: 14.0.0.Final
> Reporter: David Le Borgne
> Assignee: Parul Sharma
> Priority: Major
> Attachments: stack_trace.txt
>
>
> Pressing TAB after typing "read-attribute " in /system-property displays a java.lang.IllegalArgumentException: newValue is null message and exits JBoss CLI.
>
> {{/opt/wildfly/bin/jboss-cli.sh --connect}}
> {{[standalone@localhost:9990 /] cd /system-property}}
> {{[standalone@localhost:9990 system-property] read-attribute <TAB>}}
> {{Exception in thread "CLI Terminal Connection (uninterruptable)" java.lang.IllegalArgumentException: newValue is null}}
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
5 years, 2 months
[Red Hat JIRA] (WFCORE-5247) IllegalArgumentException and CLI crash with read-attribute in /system-property
by Chao Wang (Jira)
[ https://issues.redhat.com/browse/WFCORE-5247?page=com.atlassian.jira.plug... ]
Chao Wang commented on WFCORE-5247:
-----------------------------------
OK, I will put my found below and leave the fix and test to [~parsharma].
This looks a general issue as it not only limits to the {{system-property}} address.
For example, below commands reproduce same exception.
{code:xml}
[standalone@localhost:9990 /] cd subsystem
[standalone@localhost:9990 system-property] read-attribute TAB
{code}
https://github.com/wildfly/wildfly-core/blob/master/cli/src/main/java/org... looks not right, in case of {{node.getName()}} is null, it tries to set {{null}} as ModelNode value.
> IllegalArgumentException and CLI crash with read-attribute in /system-property
> ------------------------------------------------------------------------------
>
> Key: WFCORE-5247
> URL: https://issues.redhat.com/browse/WFCORE-5247
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI
> Affects Versions: 14.0.0.Final
> Reporter: David Le Borgne
> Assignee: Parul Sharma
> Priority: Major
> Attachments: stack_trace.txt
>
>
> Pressing TAB after typing "read-attribute " in /system-property displays a java.lang.IllegalArgumentException: newValue is null message and exits JBoss CLI.
>
> {{/opt/wildfly/bin/jboss-cli.sh --connect}}
> {{[standalone@localhost:9990 /] cd /system-property}}
> {{[standalone@localhost:9990 system-property] read-attribute <TAB>}}
> {{Exception in thread "CLI Terminal Connection (uninterruptable)" java.lang.IllegalArgumentException: newValue is null}}
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
5 years, 2 months