[JBoss JIRA] (WFLY-8997) @RunAsIdentity should cause authentication part to be skipped
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFLY-8997?page=com.atlassian.jira.plugin.... ]
Darran Lofthouse reassigned WFLY-8997:
--------------------------------------
Assignee: (was: Darran Lofthouse)
> @RunAsIdentity should cause authentication part to be skipped
> -------------------------------------------------------------
>
> Key: WFLY-8997
> URL: https://issues.jboss.org/browse/WFLY-8997
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 11.0.0.Alpha1
> Reporter: Jörg Bäsner
>
> The issue [WFLY-140|https://issues.jboss.org/browse/WFLY-140] introduced a change in behavior.
> Before this change, the SecurityContextInterceptor would just invoke the push() method on SimpleSecurityManager and that method would internally create a new security context and authenticate the incoming principal if needed. In that implementation the presence of a RunAsIdentity would cause authentication part to be skipped.
> With the changes in the above issue, the security context establishment and the authentication parts were separated and while push() still checks for a RunAsIdentity, the authenticate() implementation does not, which ends up triggering the authentication process even if a RunAsIdentity is available. There is another check in place to avoid authentication if a valid authenticated subject already exists and the security domains match but this should also be the case if the security domains do not match.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (WFCORE-3042) It is not possible to add new Elytron policy after adding and removing it first
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3042?page=com.atlassian.jira.plugi... ]
Darran Lofthouse moved WFLY-9025 to WFCORE-3042:
------------------------------------------------
Project: WildFly Core (was: WildFly)
Key: WFCORE-3042 (was: WFLY-9025)
Component/s: Security
(was: Security)
Affects Version/s: (was: 11.0.0.Alpha1)
> It is not possible to add new Elytron policy after adding and removing it first
> -------------------------------------------------------------------------------
>
> Key: WFCORE-3042
> URL: https://issues.jboss.org/browse/WFCORE-3042
> Project: WildFly Core
> Issue Type: Bug
> Components: Security
> Reporter: Jan Kašík
>
> Adding new Elytron policy fails if it was previously added and then removed. Next adding fails [1] and with exception [2] in server.log.
> [1]
> {code}
> [standalone@localhost:9990 /] /subsystem=elytron/policy=jacc:add(jacc-policy=[{name => jacc}])
> {
> "outcome" => "failed",
> "response-headers" => {
> "operation-requires-reload" => true,
> "process-state" => "reload-required"
> },
> "failure-description" => {"WFLYCTL0080: Failed services" => {"org.wildfly.security.policy" => "Failed to start service
> Caused by: java.lang.RuntimeException: Failed to set policy [org.wildfly.security.authz.jacc.JaccDelegatingPolicy@502d9a84]
> Caused by: java.lang.SecurityException: ELY03018: Cannot add permissions to a read-only permission collection"}},
> "rolled-back" => true
> }
> {code}
> [2]
> {code}
> 2017-06-29 11:08:35,700 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-4) MSC000001: Failed to start service org.wildfly.security.policy: org.jboss.msc.service.StartException in service org.wildfly.security.policy: Failed to start service
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1978)
> 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.RuntimeException: Failed to set policy [org.wildfly.security.authz.jacc.JaccDelegatingPolicy@502d9a84]
> at org.wildfly.extension.elytron.PolicyDefinitions$1$1.start(PolicyDefinitions.java:177)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:2032)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1955)
> ... 3 more
> Caused by: java.lang.SecurityException: ELY03018: Cannot add permissions to a read-only permission collection
> at org.wildfly.security.authz.jacc.JaccDelegatingPolicy$1.add(JaccDelegatingPolicy.java:126)
> at java.security.Policy.addStaticPerms(Policy.java:686)
> at java.security.Policy.getPermissions(Policy.java:673)
> at org.jboss.security.jacc.DelegatingPolicy.getPermissions(DelegatingPolicy.java:125)
> at java.security.Policy.initPolicy(Policy.java:327)
> at java.security.Policy.setPolicy(Policy.java:270)
> at org.wildfly.extension.elytron.PolicyDefinitions$1$1.lambda$setPolicyAction$0(PolicyDefinitions.java:201)
> at org.wildfly.extension.elytron.PolicyDefinitions$1$1.setPolicy(PolicyDefinitions.java:195)
> at org.wildfly.extension.elytron.PolicyDefinitions$1$1.start(PolicyDefinitions.java:173)
> ... 5 more
> 2017-06-29 11:08:35,701 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 3) WFLYCTL0013: Operation ("add") failed - address: ([
> ("subsystem" => "elytron"),
> ("policy" => "jacc")
> ]) - failure description: {"WFLYCTL0080: Failed services" => {"org.wildfly.security.policy" => "Failed to start service
> Caused by: java.lang.RuntimeException: Failed to set policy [org.wildfly.security.authz.jacc.JaccDelegatingPolicy@502d9a84]
> Caused by: java.lang.SecurityException: ELY03018: Cannot add permissions to a read-only permission collection"}}
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (WFCORE-3041) Cannot add policy resource with no parameter
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3041?page=com.atlassian.jira.plugi... ]
Darran Lofthouse moved WFLY-9056 to WFCORE-3041:
------------------------------------------------
Project: WildFly Core (was: WildFly)
Key: WFCORE-3041 (was: WFLY-9056)
Component/s: Security
(was: Security)
> Cannot add policy resource with no parameter
> --------------------------------------------
>
> Key: WFCORE-3041
> URL: https://issues.jboss.org/browse/WFCORE-3041
> Project: WildFly Core
> Issue Type: Bug
> Components: Security
> Reporter: Claudio Miranda
>
> subsystem=elytron/policy resources has no required attributes, but it fails to add a resource with no parameters.
> {code}
> /profile=full/subsystem=elytron/policy=policy_test:add
> {
> "outcome" => "failed",
> "result" => undefined,
> "failure-description" => {"WFLYDC0074: Operation failed or was rolled back on all servers. Server failures:" => {"server-group" => {"main-server-group" => {"host" => {"master" => {"server-one" => "Could find policy provider with name [policy_test]"}}}}}},
> "rolled-back" => true,
> "server-groups" => {"main-server-group" => {"host" => {"master" => {"server-one" => {"response" => {
> "outcome" => "failed",
> "failure-description" => "Could find policy provider with name [policy_test]",
> "rolled-back" => true
> }}}}}}
> }
> {code}
> To add is necessary to inform either custom-policy or jacc-policy
> {code}
> /profile=full/subsystem=elytron/policy=policy2:add(jacc-policy=[{name=policy2}])
> {
> "outcome" => "success",
> "result" => undefined,
> "server-groups" => {"main-server-group" => {"host" => {"master" => {"server-one" => {"response" => {
> "outcome" => "success",
> "response-headers" => {
> "operation-requires-reload" => true,
> "process-state" => "reload-required"
> }
> }}}}}}
> }
> {code}
> There is also a problem related to "default-policy" being set to a non existent policy.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (WFCORE-944) truststore path is ignored if provider is not JKS
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFCORE-944?page=com.atlassian.jira.plugin... ]
Darran Lofthouse reassigned WFCORE-944:
---------------------------------------
Assignee: (was: Darran Lofthouse)
> truststore path is ignored if provider is not JKS
> -------------------------------------------------
>
> Key: WFCORE-944
> URL: https://issues.jboss.org/browse/WFCORE-944
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Security
> Reporter: Arto Huusko
>
> truststore configuration ignores the path and relative-to parameters if the truststore provider is anything else than JKS.
> This works as documented, but it is not correct. There can be and are truststore implementations that need to load parameters or whatever data from a file, and the current implementation prevents these truststore providers from working.
> We have a custom truststore that is loaded from database, and database access parameters are read from a properties file. When trying to use this with Wildfly 9, the keystore engineLoad parameter is passed in as null, even though path and relative-to are configured.
> Even standard java supports PKCS12 truststores, where the same problem would occur.
> So I would suggest that
> - if provider is JKS, path is mandatory
> - if provider is not JKS, but path is specified, it is passed to the provider
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (WFCORE-1282) Unable to create HTTPS connection using *ECDH_RSA* cipher suites / kECDHr cipher string
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1282?page=com.atlassian.jira.plugi... ]
Darran Lofthouse updated WFCORE-1282:
-------------------------------------
Fix Version/s: (was: 3.0.0.Beta29)
> Unable to create HTTPS connection using *ECDH_RSA* cipher suites / kECDHr cipher string
> ---------------------------------------------------------------------------------------
>
> Key: WFCORE-1282
> URL: https://issues.jboss.org/browse/WFCORE-1282
> Project: WildFly Core
> Issue Type: Bug
> Components: Security
> Affects Versions: 1.0.2.Final
> Environment: Oracle Java
> Reporter: Martin Choma
> Assignee: Darran Lofthouse
> Priority: Critical
> Attachments: client_debug_eap6.log, client_debug_eap7.log, server-cert-key-ec.jks, server_debug_eap6.log, server_debug_eap7.log
>
>
> User using these cipher suites / cipher name in EAP6 won't be able to use it in EAP7.
> Setting as critical as these cipher suites, are considered for strong and widely used in my opinion.
> In server log, error "no cipher suites in common" can be seen using -Djavax.net.debug=all.
> Note, that analogous configuration in EAP6 works fine.
> Issue can be seen on Oracle Java only, as on OpenJDK / IBM these suites are not provided by method getDefaultCipherSuites().
> Also is it possible to log "no cipher suites in common" and similar tls handshake errors without -Djavax.net.debug for better troubleshooting?
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (WFCORE-1282) Unable to create HTTPS connection using *ECDH_RSA* cipher suites / kECDHr cipher string
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1282?page=com.atlassian.jira.plugi... ]
Darran Lofthouse reassigned WFCORE-1282:
----------------------------------------
Assignee: (was: Darran Lofthouse)
> Unable to create HTTPS connection using *ECDH_RSA* cipher suites / kECDHr cipher string
> ---------------------------------------------------------------------------------------
>
> Key: WFCORE-1282
> URL: https://issues.jboss.org/browse/WFCORE-1282
> Project: WildFly Core
> Issue Type: Bug
> Components: Security
> Affects Versions: 1.0.2.Final
> Environment: Oracle Java
> Reporter: Martin Choma
> Priority: Critical
> Attachments: client_debug_eap6.log, client_debug_eap7.log, server-cert-key-ec.jks, server_debug_eap6.log, server_debug_eap7.log
>
>
> User using these cipher suites / cipher name in EAP6 won't be able to use it in EAP7.
> Setting as critical as these cipher suites, are considered for strong and widely used in my opinion.
> In server log, error "no cipher suites in common" can be seen using -Djavax.net.debug=all.
> Note, that analogous configuration in EAP6 works fine.
> Issue can be seen on Oracle Java only, as on OpenJDK / IBM these suites are not provided by method getDefaultCipherSuites().
> Also is it possible to log "no cipher suites in common" and similar tls handshake errors without -Djavax.net.debug for better troubleshooting?
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (WFCORE-1153) Can't configure empty base-dn for ldap realm
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1153?page=com.atlassian.jira.plugi... ]
Darran Lofthouse reassigned WFCORE-1153:
----------------------------------------
Assignee: (was: Darran Lofthouse)
> Can't configure empty base-dn for ldap realm
> --------------------------------------------
>
> Key: WFCORE-1153
> URL: https://issues.jboss.org/browse/WFCORE-1153
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management, Security
> Affects Versions: 2.0.2.Final
> Reporter: Alberto Persello
> Labels: authentication, authorization, group, ldap, realm
>
> It is not possible to set the empty value for base-dn attribute in authentication-->ldap element and in authorization-->ldap-->group-search-->group-to-principal element.
> The empty value is the only valid option for java ldap searches to scan the entire ldap (the equivalent of RootDSE).
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (WFCORE-1533) Integrate Management Access Control permission assignment with Elytron
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1533?page=com.atlassian.jira.plugi... ]
Darran Lofthouse reassigned WFCORE-1533:
----------------------------------------
Assignee: (was: Darran Lofthouse)
> Integrate Management Access Control permission assignment with Elytron
> ----------------------------------------------------------------------
>
> Key: WFCORE-1533
> URL: https://issues.jboss.org/browse/WFCORE-1533
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Domain Management, Security
> Reporter: Darran Lofthouse
> Labels: affects_elytron
> Fix For: 4.0.0.Beta1
>
>
> A big portion of management role based access control is taking the assigned roles and then mapping these to the permissions for that role.
> Elytron provides a new PermissionMapper interface that takes a SecurityIdentity and the roles mapped for that identity and returns a PermissionVerifier which can be as simple as a wrapper around a PermissionCollection.
> This will also be a good opportunity to start to move the role mapping out of the core management model to Elytron.
> After that Elytron allows for custom PermissionMapper implementations to be provided and associated with the domain using capabilities and requirements so we arrive at a point where provided the permission checks performed by management are generic enough custom PermissionMapper / PermissionVerifier implementations can be added that may or may not be role based.
> _Note: As with everything we are doing old and new need to be supported in parallel for a while although this may be achieved by providing default Elytron implementations that are wrappers around the old._
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (WFCORE-1332) Referrals 'throw' does not work correctly for ldap authentication to mgmt console with MS Active Directory
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1332?page=com.atlassian.jira.plugi... ]
Darran Lofthouse reassigned WFCORE-1332:
----------------------------------------
Assignee: (was: Ivo Studensky)
> Referrals 'throw' does not work correctly for ldap authentication to mgmt console with MS Active Directory
> ----------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-1332
> URL: https://issues.jboss.org/browse/WFCORE-1332
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management, Security
> Affects Versions: 2.0.7.Final
> Reporter: Ondrej Lukas
>
> In case when crossRef object to different domain is configured on MS Active Directory for handling referrals and JBoss EAP 7 uses ldap authentication to mgmt console with configured referrals 'throw' then authentication fails for referral users. It is inconsistent with behavior of EAP with another LDAP providers (e.g. Red Hat Directory Server). In correct behavior authentication should pass.
> It seems it is caused by thrown LdapReferralException search method of org.jboss.as.domain.management.security.LdapUserSearcherFactory.LdapUserSearcherImpl before it is handled by try-catch block. Stack trace of thrown LdapReferralException:
> com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:2975)
> com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:2888)
> com.sun.jndi.ldap.LdapCtx.searchAux(LdapCtx.java:1846)
> com.sun.jndi.ldap.LdapCtx.c_search(LdapCtx.java:1769)
> com.sun.jndi.ldap.LdapCtx.c_search(LdapCtx.java:1786)
> com.sun.jndi.toolkit.ctx.ComponentDirContext.p_search(ComponentDirContext.java:418)
> com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.search(PartialCompositeDirContext.java:396)
> com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.search(PartialCompositeDirContext.java:378)
> javax.naming.directory.InitialDirContext.search(InitialDirContext.java:286)
> javax.naming.directory.InitialDirContext.search(InitialDirContext.java:286)
> org.jboss.as.domain.management.security.LdapUserSearcherFactory$LdapUserSearcherImpl.search(LdapUserSearcherFactory.java:125)
> org.jboss.as.domain.management.security.LdapUserSearcherFactory$LdapUserSearcherImpl.search(LdapUserSearcherFactory.java:66)
> org.jboss.as.domain.management.security.LdapCacheService$NoCacheCache.search(LdapCacheService.java:225)
> org.jboss.as.domain.management.security.UserLdapCallbackHandler$LdapCallbackHandler.handle(UserLdapCallbackHandler.java:205)
> org.jboss.as.domain.management.security.SecurityRealmService$1.handle(SecurityRealmService.java:178)
> org.jboss.as.domain.http.server.security.RealmIdentityManager.verify(RealmIdentityManager.java:162)
> org.jboss.as.domain.http.server.security.RealmIdentityManager.verify(RealmIdentityManager.java:141)
> io.undertow.security.impl.BasicAuthenticationMechanism.authenticate(BasicAuthenticationMechanism.java:118)
> org.jboss.as.domain.http.server.security.AuthenticationMechanismWrapper.authenticate(AuthenticationMechanismWrapper.java:52)
> io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(SecurityContextImpl.java:233)
> io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(SecurityContextImpl.java:250)
> io.undertow.security.impl.SecurityContextImpl$AuthAttempter.access$100(SecurityContextImpl.java:219)
> io.undertow.security.impl.SecurityContextImpl.attemptAuthentication(SecurityContextImpl.java:121)
> io.undertow.security.impl.SecurityContextImpl.authTransition(SecurityContextImpl.java:96)
> io.undertow.security.impl.SecurityContextImpl.authenticate(SecurityContextImpl.java:89)
> io.undertow.security.handlers.AuthenticationCallHandler.handleRequest(AuthenticationCallHandler.java:50)
> io.undertow.server.Connectors.executeRootHandler(Connectors.java:202)
> io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:793)
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> java.lang.Thread.run(Thread.java:745)
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (WFLY-9062) Handle TERM cleanly
by Ben Parees (JIRA)
Ben Parees created WFLY-9062:
--------------------------------
Summary: Handle TERM cleanly
Key: WFLY-9062
URL: https://issues.jboss.org/browse/WFLY-9062
Project: WildFly
Issue Type: Feature Request
Components: Server
Reporter: Ben Parees
Assignee: Jason Greene
The wildfly server currently terminates immediately in response to a TERM signal. To achieve a clean shutdown requires invoking the CLI tooling. This is particularly problematic in container environments like kubernetes where the container process (wildfly in this case) is going to get a TERM signal when the container needs to be moved.
While it's possible to wrapper the process and handle the TERM and then invoke the CLI, it would be preferable for the server process itself to cleanly handle a TERM signal by waiting for in-flight requests to complete (w/ some grace period of course).
Having this as configurable behavior would be good if there are backwards compatibility concerns about introducing this behavior change.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months