[JBoss JIRA] (ELY-1186) Elytron - authentication fails when a realm name is not specified for DIGEST-MD5 mechanism on server side
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/ELY-1186?page=com.atlassian.jira.plugin.s... ]
David Lloyd commented on ELY-1186:
----------------------------------
Suggesting a host name for the realm name seems wrong, like something got mixed up somewhere.
> Elytron - authentication fails when a realm name is not specified for DIGEST-MD5 mechanism on server side
> ---------------------------------------------------------------------------------------------------------
>
> Key: ELY-1186
> URL: https://issues.jboss.org/browse/ELY-1186
> Project: WildFly Elytron
> Issue Type: Bug
> Reporter: Josef Cacek
> Assignee: Darran Lofthouse
> Priority: Blocker
>
> When a default configuration is used for DIGEST-MD5 SASL mechanism, then server suggest hostname as a realm name, but authentication fails because ServerAuthenticationContext checks mechanism configuration and fails with following exception:
> {code}
> @Message(id = 1092, value = "Invalid mechanism realm selection \"%s\"")
> IllegalArgumentException invalidMechRealmSelection(String realmName);
> {code}
> *Suggested fix:*
> If the server suggests realm name, then it should be able to consume it. Or if the realm name is really mandatory, then server should not suggest such a default value. IMO allowing such a default and simplifying configuration would have positive impact on user experience.
> The full stacktrace (hidden):
> {noformat}
> javax.security.sasl.SaslException: ELY05053: [DIGEST-MD5] Callback handler failed for unknown reason [Caused by java.lang.IllegalArgumentException: ELY01092: Invalid mechanism realm selection "localhost"]
> at org.wildfly.security.sasl.util.AbstractSaslParticipant.tryHandleCallbacks(AbstractSaslParticipant.java:105)
> at org.wildfly.security.sasl.digest.AbstractDigestMechanism.getPredigestedSaltedPassword(AbstractDigestMechanism.java:482)
> at org.wildfly.security.sasl.digest.DigestSaslServer.validateDigestResponse(DigestSaslServer.java:259)
> at org.wildfly.security.sasl.digest.DigestSaslServer.evaluateMessage(DigestSaslServer.java:355)
> at org.wildfly.security.sasl.util.AbstractSaslParticipant.evaluateMessage(AbstractSaslParticipant.java:180)
> at org.wildfly.security.sasl.digest.DigestSaslServer.evaluateResponse(DigestSaslServer.java:328)
> at org.wildfly.security.sasl.util.AuthenticationCompleteCallbackSaslServerFactory$1.evaluateResponse(AuthenticationCompleteCallbackSaslServerFactory.java:58)
> at org.wildfly.security.sasl.util.AuthenticationTimeoutSaslServerFactory$DelegatingTimeoutSaslServer.evaluateResponse(AuthenticationTimeoutSaslServerFactory.java:106)
> at org.wildfly.security.sasl.util.SecurityIdentitySaslServerFactory$1.evaluateResponse(SecurityIdentitySaslServerFactory.java:57)
> at org.xnio.sasl.SaslUtils.evaluateResponse(SaslUtils.java:245)
> at org.xnio.sasl.SaslUtils.evaluateResponse(SaslUtils.java:217)
> at org.jboss.remoting3.remote.ServerConnectionOpenListener$AuthStepRunnable.run(ServerConnectionOpenListener.java:470)
> at org.jboss.remoting3.EndpointImpl$TrackingExecutor.lambda$execute$0(EndpointImpl.java:897)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: java.lang.IllegalArgumentException: ELY01092: Invalid mechanism realm selection "localhost"
> at org.wildfly.security.auth.server.ServerAuthenticationContext$InitialState.setMechanismRealmName(ServerAuthenticationContext.java:1615)
> at org.wildfly.security.auth.server.ServerAuthenticationContext.setMechanismRealmName(ServerAuthenticationContext.java:712)
> at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handleOne(ServerAuthenticationContext.java:927)
> at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handle(ServerAuthenticationContext.java:735)
> at org.wildfly.security.sasl.util.TrustManagerSaslServerFactory.lambda$createSaslServer$0(TrustManagerSaslServerFactory.java:96)
> at org.wildfly.security.sasl.util.AbstractSaslParticipant.tryHandleCallbacks(AbstractSaslParticipant.java:101)
> ... 15 more
> {noformat}
> Attached also server configuration and WireShark log.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 1 month
[JBoss JIRA] (WFCORE-2349) Add RemoteManagementPermission and RemoteJMXPermission checks for remote clients.
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2349?page=com.atlassian.jira.plugi... ]
Brian Stansberry edited comment on WFCORE-2349 at 5/25/17 3:07 PM:
-------------------------------------------------------------------
Some discussion notes on this. The discussion reference to '2' and '3' means software based on WildFly Core 2.x vs 3:
[11:25 AM] Darran Lofthouse: As we move to Elytron based SecurityIdentities as a connection to a service is established we can call SecurityIdentity.implies(org.jboss.ejb.client.RemoteEJBPermission) - we already have some new permissions for some services. These permissions are granted in the default Elytron config and also the legacy security realms grant all the permissions as there was no permission check in 2. The Jira is to add a permission check for a remote management connection and update the default Elytron config and legacy realms to grant the permission.
[11:26 AM] Darran Lofthouse: Any users of 3 starting from the default config would be better to know about these permissions today and have them in the default config
[12:54 PM] Brian Stansberry: @DarranLofthouse sorry; I got distracted. :( so this isn't really a security manager permission, it's an extra server side authorization check beyond simple 1) can the user authenticate and 2) RBAC checks
[12:55 PM] Brian Stansberry: that seems ok. I misinterpreted it before as a client side security manager perm thing, where the client would pass that check and thereafter the call would be privileged and the calling code would not need the misc remoting etc perms
[1:00 PM] Darran Lofthouse: @BrianStansberry +1 it is actually somewhere between #1 and #2 - do they have permission to connect to this specific service - so where all Remoting services are available from a single Endpoint establishing a connection doesn't give an automatic right to use anything (Unless they are using legacy security realms where we do grant them all for compatibility)
[1:02 PM] Brian Stansberry: ah, good point; I never like management-interface=<iforget> that used the subsystem endpoint because of that problem
was (Author: brian.stansberry):
Some discussion notes on this:
[11:25 AM] Darran Lofthouse: As we move to Elytron based SecurityIdentities as a connection to a service is established we can call SecurityIdentity.implies(org.jboss.ejb.client.RemoteEJBPermission) - we already have some new permissions for some services. These permissions are granted in the default Elytron config and also the legacy security realms grant all the permissions as there was no permission check in 2. The Jira is to add a permission check for a remote management connection and update the default Elytron config and legacy realms to grant the permission.
[11:26 AM] Darran Lofthouse: Any users of 3 starting from the default config would be better to know about these permissions today and have them in the default config
[12:54 PM] Brian Stansberry: @DarranLofthouse sorry; I got distracted. :( so this isn't really a security manager permission, it's an extra server side authorization check beyond simple 1) can the user authenticate and 2) RBAC checks
[12:55 PM] Brian Stansberry: that seems ok. I misinterpreted it before as a client side security manager perm thing, where the client would pass that check and thereafter the call would be privileged and the calling code would not need the misc remoting etc perms
[1:00 PM] Darran Lofthouse: @BrianStansberry +1 it is actually somewhere between #1 and #2 - do they have permission to connect to this specific service - so where all Remoting services are available from a single Endpoint establishing a connection doesn't give an automatic right to use anything (Unless they are using legacy security realms where we do grant them all for compatibility)
[1:02 PM] Brian Stansberry: ah, good point; I never like management-interface=<iforget> that used the subsystem endpoint because of that problem
> Add RemoteManagementPermission and RemoteJMXPermission checks for remote clients.
> ---------------------------------------------------------------------------------
>
> Key: WFCORE-2349
> URL: https://issues.jboss.org/browse/WFCORE-2349
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Domain Management, Security
> Reporter: Darran Lofthouse
> Fix For: 3.0.0.Beta24
>
>
> Other services such as EJB and transactions have a Remote*Permission to verify the remote client has the required permission to use that service - this should be repeated for the management related services to control what a remote client can and can not connect to.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 1 month
[JBoss JIRA] (WFCORE-2349) Add RemoteManagementPermission and RemoteJMXPermission checks for remote clients.
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2349?page=com.atlassian.jira.plugi... ]
Brian Stansberry reassigned WFCORE-2349:
----------------------------------------
Fix Version/s: 3.0.0.Beta24
(was: 4.0.0.Alpha1)
Assignee: (was: ehsavoie Hugonnet)
Some discussion notes on this:
[11:25 AM] Darran Lofthouse: As we move to Elytron based SecurityIdentities as a connection to a service is established we can call SecurityIdentity.implies(org.jboss.ejb.client.RemoteEJBPermission) - we already have some new permissions for some services. These permissions are granted in the default Elytron config and also the legacy security realms grant all the permissions as there was no permission check in 2. The Jira is to add a permission check for a remote management connection and update the default Elytron config and legacy realms to grant the permission.
[11:26 AM] Darran Lofthouse: Any users of 3 starting from the default config would be better to know about these permissions today and have them in the default config
[12:54 PM] Brian Stansberry: @DarranLofthouse sorry; I got distracted. :( so this isn't really a security manager permission, it's an extra server side authorization check beyond simple 1) can the user authenticate and 2) RBAC checks
[12:55 PM] Brian Stansberry: that seems ok. I misinterpreted it before as a client side security manager perm thing, where the client would pass that check and thereafter the call would be privileged and the calling code would not need the misc remoting etc perms
[1:00 PM] Darran Lofthouse: @BrianStansberry +1 it is actually somewhere between #1 and #2 - do they have permission to connect to this specific service - so where all Remoting services are available from a single Endpoint establishing a connection doesn't give an automatic right to use anything (Unless they are using legacy security realms where we do grant them all for compatibility)
[1:02 PM] Brian Stansberry: ah, good point; I never like management-interface=<iforget> that used the subsystem endpoint because of that problem
> Add RemoteManagementPermission and RemoteJMXPermission checks for remote clients.
> ---------------------------------------------------------------------------------
>
> Key: WFCORE-2349
> URL: https://issues.jboss.org/browse/WFCORE-2349
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Domain Management, Security
> Reporter: Darran Lofthouse
> Fix For: 3.0.0.Beta24
>
>
> Other services such as EJB and transactions have a Remote*Permission to verify the remote client has the required permission to use that service - this should be repeated for the management related services to control what a remote client can and can not connect to.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 1 month
[JBoss JIRA] (DROOLS-1583) Refactor KnowledgeBaseImpl
by Mario Fusco (JIRA)
Mario Fusco created DROOLS-1583:
-----------------------------------
Summary: Refactor KnowledgeBaseImpl
Key: DROOLS-1583
URL: https://issues.jboss.org/browse/DROOLS-1583
Project: Drools
Issue Type: Enhancement
Components: core engine
Reporter: Mario Fusco
Assignee: Mario Fusco
It is required to review the KnowledgeBaseImpl and lower the technical debt accumulated on it by:
# Remove unnecessary duplicated methods that at the moment are there only for backward compatibility reasons.
# Review the locks and in particular check if some of them can be removed since now the kbase changes are enqueued.
# Review the rules/packages addition lifecycle emitting events before and after them (and in general reviewing the existing events).
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 1 month
[JBoss JIRA] (WFLY-8846) Cannot set max-save-post-size to -1
by Robert Bost (JIRA)
Robert Bost created WFLY-8846:
---------------------------------
Summary: Cannot set max-save-post-size to -1
Key: WFLY-8846
URL: https://issues.jboss.org/browse/WFLY-8846
Project: WildFly
Issue Type: Bug
Affects Versions: 10.1.0.Final
Reporter: Robert Bost
Assignee: Jason Greene
JBossWeb allows for the max save post size to be -1 but the web subsystem connector config validator blocks negative values.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 1 month
[JBoss JIRA] (WFLY-8845) Cannot set max-save-post-size to -1
by Robert Bost (JIRA)
Robert Bost created WFLY-8845:
---------------------------------
Summary: Cannot set max-save-post-size to -1
Key: WFLY-8845
URL: https://issues.jboss.org/browse/WFLY-8845
Project: WildFly
Issue Type: Bug
Affects Versions: 10.1.0.Final
Reporter: Robert Bost
Assignee: Jason Greene
JBossWeb allows for the max save post size to be -1 but the web subsystem connector config validator blocks negative values.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 1 month
[JBoss JIRA] (LOGMGR-160) Fix JavaDoc for the SizeRotatingFileHander.setSuffix()
by James Perkins (JIRA)
James Perkins created LOGMGR-160:
------------------------------------
Summary: Fix JavaDoc for the SizeRotatingFileHander.setSuffix()
Key: LOGMGR-160
URL: https://issues.jboss.org/browse/LOGMGR-160
Project: JBoss Log Manager
Issue Type: Bug
Reporter: James Perkins
The JavaDoc for the {{SizeRotatingFileSystem.setSuffix()}} indicates that files will not be deleted when deleted. However there are multiple rotations for the same date they will be purged.
For example if the suffix is {{.yyyy-DD-mm}}, the size was reached 20 times on the same day and the {{maxBackupIndex}} was set to 10 there will only be 10 files kept.What won't be purged is files from a previous day.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 1 month