[JBoss JIRA] (WFLY-9855) [JDK9+] org.jboss.security.negotiation.spnego package is exported by two jars
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFLY-9855?page=com.atlassian.jira.plugin.... ]
Darran Lofthouse reassigned WFLY-9855:
--------------------------------------
Assignee: (was: Darran Lofthouse)
> [JDK9+] org.jboss.security.negotiation.spnego package is exported by two jars
> -----------------------------------------------------------------------------
>
> Key: WFLY-9855
> URL: https://issues.jboss.org/browse/WFLY-9855
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Reporter: Tomaz Cerar
> Priority: Critical
>
> Currently if you have
> jboss-negotiation-spnego-3.0.4.Final and jboss-negotiation-extras-3.0.4.Final.jar
> on your module path, jvm complains as both jars export package org.jboss.security.negotiation.spnego
> which violates the modules contract where only one module (jar) can provide single package.
> example error that jvm prints
> {noformat}
> Error: Modules jboss.negotiation.extras and jboss.negotiation.spnego export package org.jboss.security.negotiation.spnego to module wildfly.clustering.common
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
5 years, 4 months
[JBoss JIRA] (WFCORE-3876) Composite operation on filesystem-realm blocks management operations
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3876?page=com.atlassian.jira.plugi... ]
Darran Lofthouse reassigned WFCORE-3876:
----------------------------------------
Assignee: (was: Darran Lofthouse)
> Composite operation on filesystem-realm blocks management operations
> --------------------------------------------------------------------
>
> Key: WFCORE-3876
> URL: https://issues.jboss.org/browse/WFCORE-3876
> Project: WildFly Core
> Issue Type: Bug
> Components: Security
> Reporter: Claudio Miranda
>
> There is a problem when adding an identity and an attribute on filesystem-realm as composite operation, it blocks the operation, but also blocks some other operations, for example, while the composite operation run, the other following operations just blocks. This problem only occurs in domain mode.
> The filesystem-realm=file1 was created with no errors.
> Add an identity and a identity attribute as composite operation
> {code}
> batch
> /host=master/server=server-three/subsystem=elytron/filesystem-realm=file1:add-identity(identity=user3)
> /host=master/server=server-three/subsystem=elytron/filesystem-realm=file1:add-identity-attribute(identity=user3,name=key1,value=[val1,val11])
> run-batch
> {code}
> The following composite, also blocks the same way (for an existing identity named user3)
> {code}
> batch
> /host=master/server=server-three/subsystem=elytron/filesystem-realm=file1:add-identity-attribute(identity=user3,name=key3,value=[val3,val33])
> /host=master/server=server-three/subsystem=elytron/filesystem-realm=file1:add-identity-attribute(identity=user3,name=key4,value=[val4,val44])
> run-batch
> {code}
> The following operation just blocks waiting the above operation to finish.
> {code}
> /host=master/server=server-three/subsystem=elytron/filesystem-realm=file1:read-identity(identity=other)
> {code}
> {code}
> /profile=full-ha/subsystem=elytron/filesystem-realm=file3:add(path=file3)
> {code}
> {code}
> /profile=full-ha/subsystem=elytron/properties-realm=props1:add(users-properties={path=application-users.properties,relative-to=jboss.domain.config.dir,digest-realm-name=ApplicationRealm})
> {code}
> It also blocks write-attribute operation on other subsystems
> {code}
> /profile=full-ha/subsystem=io/worker=default:write-attribute(name=task-max-threads,value=100)
> /profile=full-ha/subsystem=datasources/data-source=ExampleDS:write-attribute(name=max-pool-size,value=12)
> {code}
> The last operation reports as a non-progressing operation
> {code}
> /host=master/core-service=management/service=management-operations:find-non-progressing-operation
> {
> "outcome" => "success",
> "result" => "500616352"
> }
> [domain@localhost:9990 /] /host=master/core-service=management/service=management-operations/active-operation=*:read-resource
> {
> "outcome" => "success",
> "result" => [
> {
> "address" => [
> ("host" => "master"),
> ("core-service" => "management"),
> ("service" => "management-operations"),
> ("active-operation" => "-886331830")
> ],
> "outcome" => "success",
> "result" => {
> "access-mechanism" => "NATIVE",
> "address" => [
> ("host" => "master"),
> ("core-service" => "management"),
> ("service" => "management-operations"),
> ("active-operation" => "*")
> ],
> "caller-thread" => "management-handler-thread - 15",
> "cancelled" => false,
> "domain-rollout" => false,
> "domain-uuid" => undefined,
> "exclusive-running-time" => -1L,
> "execution-status" => "executing",
> "operation" => "read-resource",
> "running-time" => 2341554L
> }
> },
> {
> "address" => [
> ("host" => "master"),
> ("core-service" => "management"),
> ("service" => "management-operations"),
> ("active-operation" => "-199839257")
> ],
> "outcome" => "success",
> "result" => {
> "access-mechanism" => "NATIVE",
> "address" => [],
> "caller-thread" => "management-handler-thread - 13",
> "cancelled" => false,
> "domain-rollout" => false,
> "domain-uuid" => undefined,
> "exclusive-running-time" => -1L,
> "execution-status" => "executing",
> "operation" => "composite",
> "running-time" => 37961295588L
> }
> },
> {
> "address" => [
> ("host" => "master"),
> ("core-service" => "management"),
> ("service" => "management-operations"),
> ("active-operation" => "500616352")
> ],
> "outcome" => "success",
> "result" => {
> "access-mechanism" => "NATIVE",
> "address" => [
> ("profile" => "full-ha"),
> ("subsystem" => "io"),
> ("worker" => "default")
> ],
> "caller-thread" => "management-handler-thread - 14",
> "cancelled" => false,
> "domain-rollout" => false,
> "domain-uuid" => "87a864ef-e287-4436-acd5-4842459dfc2e",
> "exclusive-running-time" => 33671893306L,
> "execution-status" => "executing",
> "operation" => "write-attribute",
> "running-time" => 33671782128L
> }
> }
> ]
> }
> {code}
> After the operation timeout, the second step of the composite operation as error.
> {code}
> The batch failed with the following error (you are remaining in the batch editing mode to have a chance to correct the error):
> WFLYCTL0062: Composite operation failed and was rolled back. Steps that failed:
> Step: step-2
> Operation: /host=master/server=server-three/subsystem=elytron/filesystem-realm=file1:add-identity-attribute(identity=user3,name=key1,value=[val1,val11])
> Failure: WFLYCTL0409: Execution of operation 'add-identity-attribute' on remote process at address '[
> ("host" => "master"),
> ("server" => "server-three")
> ]' timed out after 305000 ms while awaiting initial response; remote process has been notified to terminate operation
> {code}
> I understand that to add the identity attribute, it should run as non composite, and it works, but the problem is the blocking it does on the other operations.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
5 years, 4 months
[JBoss JIRA] (WFLY-9702) SSO Integration for Programmatic Authentication
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFLY-9702?page=com.atlassian.jira.plugin.... ]
Darran Lofthouse reassigned WFLY-9702:
--------------------------------------
Assignee: (was: Darran Lofthouse)
> SSO Integration for Programmatic Authentication
> -----------------------------------------------
>
> Key: WFLY-9702
> URL: https://issues.jboss.org/browse/WFLY-9702
> Project: WildFly
> Issue Type: Feature Request
> Components: Clustering, Security, Web (Undertow)
> Reporter: Darran Lofthouse
> Priority: Critical
>
> At the moment the SSO integration only fully covers authentication mechanisms as they can be wrapped, we need to revisit for programmatic authentication.
> In this scenario we don't have either a wrapped mechanism or a CallbackHandler.
> Couple of options: -
> * Can we get away with pushing in some form of IdentityCache factory the mechs can obtain from the request? This may miss the additional notifications the SSO impl depends on.
> * Can we also better support listening for the notifications without the need for wrappers? This could cover both mechs and programmatic authentication?
> * Instead do we make the programmatic authenticator pluggable, i.e. push in an SSO aware impl, it can choose how to handle it's own caching and also doesn't need the notifications as it is in control of that stage of the process.
> *
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
5 years, 4 months
[JBoss JIRA] (WFLY-9212) Cannot control what principal JAASIdentityManagerImpl for SecurityContextUtil#createSubjectInfo(Principal, Object, Subject)
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFLY-9212?page=com.atlassian.jira.plugin.... ]
Darran Lofthouse reassigned WFLY-9212:
--------------------------------------
Assignee: (was: Darran Lofthouse)
> Cannot control what principal JAASIdentityManagerImpl for SecurityContextUtil#createSubjectInfo(Principal, Object,Subject)
> --------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-9212
> URL: https://issues.jboss.org/browse/WFLY-9212
> Project: WildFly
> Issue Type: Feature Request
> Components: Security
> Affects Versions: 10.1.0.Final
> Reporter: Scott Stark
>
> I have a custom JWT based auth method and JAAS login module that I'm testing with swarm which is using WFLY 10.1.0.Final. I am not able to install a custom Principal instance for retrieval via the JAX-RS javax.ws.rs.core.SecurityContext#getUserPrincipal() because of how the JAASIdentityManagerImpl#verifyCredential(final AccountImpl account, final Object credential) method populates the SecurityContext.SecurityContextUtil SubjectInfo.
> The following line:
> https://github.com/wildfly/wildfly/blob/c3332cec0c9bc5dc57899c2ae7ba26dd0...
> sc.getUtil().createSubjectInfo(incomingPrincipal, credential, subject);
> Is using the incomingPrincipal, which is derived from the simple AccountImpl wrapping of the incoming String id. In my call path, this is the user id before any authentication has happened as there is no originalPrincipal value on the AccountImpl, so it is not the best representation of the authenticated caller, and the wrapping Principal instance does not exist amongst the authenticated Subject#getPrincipals().
> I see this is due to a CallerPrincipal issue:
> https://issues.jboss.org/browse/WFLY-3626
> but one needs to be able to control what form of the authenticated userPrincipal that is returned by the user facing container getUserPrincipal() type of API calls.
> See the getPrincipalClass() unit test in this repo for an example of what is being tested:
> https://github.com/MicroProfileJWT/microprofile-jwt-auth-wfswarm/blob/f39...
> I can work around this by overriding the SubjectInfo by immediately after the auth mechanism has called the SecurityContext#authenticationComplete(...) using:
> // Workaround authenticated JWTPrincipal not being installed as user principal
> org.jboss.security.SecurityContext jbSC = SecurityContextAssociation.getSecurityContext();
> Subject subject = jbSC.getUtil().getSubject();
> jbSC.getUtil().createSubjectInfo(jwtPrincipal, bearerToken, subject);
> I have tried wrapping the Account passed into SecurityContext#authenticationComplete(...) and that has not worked so far, but I'll look again to see if there is something else I can override to achieve the desired behavior.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
5 years, 4 months
[JBoss JIRA] (WFLY-10042) Elytron tests fail intermittently
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFLY-10042?page=com.atlassian.jira.plugin... ]
Darran Lofthouse reassigned WFLY-10042:
---------------------------------------
Assignee: (was: Darran Lofthouse)
> Elytron tests fail intermittently
> ---------------------------------
>
> Key: WFLY-10042
> URL: https://issues.jboss.org/browse/WFLY-10042
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Reporter: Stuart Douglas
>
> The JMX MBean server service does not have correct dependencies set on the security domain, and as a result unregistering the Arquillian MBean can fail on reload.
> If this happen all subsequent tests will fail as the Arquillian service will not start correctly.
> An example run is at: https://ci.wildfly.org/viewLog.html?buildId=89151&buildTypeId=WFPR&tab=bu...
> {code}
> 2018-02-12 09:31:55,112 INFO [org.wildfly.extension.undertow] (ServerService Thread Pool -- 31) WFLYUT0022: Unregistered web context: '/chained-principal-transformer-transform-transformed' from server 'default-server'
> 2018-02-12 09:31:55,118 INFO [org.jboss.as.server.deployment] (MSC service thread 1-1) WFLYSRV0028: Stopped deployment chained-principal-transformer-transform-transformed.war (runtime-name: chained-principal-transformer-transform-transformed.war) in 6ms
> 2018-02-12 09:31:55,129 INFO [org.jboss.as.repository] (management-handler-thread - 1) WFLYDR0002: Content removed from location /store/work/tc-work/9ccd5e119c4a65d0/testsuite/integration/elytron/target/wildfly/standalone/data/content/7b/30341090e956f73f2066f8e357380151a337e8/content
> 2018-02-12 09:31:55,129 INFO [org.jboss.as.server] (management-handler-thread - 1) WFLYSRV0009: Undeployed "chained-principal-transformer-transform-transformed.war" (runtime-name: "chained-principal-transformer-transform-transformed.war")
> 2018-02-12 09:31:55,563 ERROR [org.jboss.as.arquillian] (MSC service thread 1-8) Cannot stop Arquillian Test Runner: java.lang.IllegalStateException
> at org.jboss.msc.value.InjectedValue.getValue(InjectedValue.java:47)
> at org.jboss.as.controller.access.management.ManagementSecurityIdentitySupplier.get(ManagementSecurityIdentitySupplier.java:60)
> at org.jboss.as.controller.access.management.ManagementSecurityIdentitySupplier.get(ManagementSecurityIdentitySupplier.java:39)
> at org.jboss.as.jmx.PluggableMBeanServerImpl.log(PluggableMBeanServerImpl.java:1180)
> at org.jboss.as.jmx.MBeanServerAuditLogRecordFormatter.log(MBeanServerAuditLogRecordFormatter.java:331)
> at org.jboss.as.jmx.MBeanServerAuditLogRecordFormatter.isRegistered(MBeanServerAuditLogRecordFormatter.java:176)
> at org.jboss.as.jmx.PluggableMBeanServerImpl.isRegistered(PluggableMBeanServerImpl.java:784)
> at org.jboss.arquillian.protocol.jmx.JMXTestRunner.unregisterMBean(JMXTestRunner.java:109)
> at org.jboss.as.arquillian.service.ArquillianService.stop(ArquillianService.java:96)
> at org.jboss.msc.service.ServiceControllerImpl$StopTask.stopService(ServiceControllerImpl.java:1767)
> at org.jboss.msc.service.ServiceControllerImpl$StopTask.execute(ServiceControllerImpl.java:1740)
> at org.jboss.msc.service.ServiceControllerImpl$ControllerTask.run(ServiceControllerImpl.java:1527)
> at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1979)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1481)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1360)
> at java.lang.Thread.run(Thread.java:748)
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
5 years, 4 months