[JBoss JIRA] (WFCORE-2641) Authentication through http-interface with Elytron authentication and legacy SSL (without configured authentication) is not possible
by ehsavoie Hugonnet (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2641?page=com.atlassian.jira.plugi... ]
ehsavoie Hugonnet resolved WFCORE-2641.
---------------------------------------
Fix Version/s: 3.0.0.Beta26
Assignee: Darran Lofthouse
Resolution: Done
Resolved as JBEAP cloned from is verified
> Authentication through http-interface with Elytron authentication and legacy SSL (without configured authentication) is not possible
> ------------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-2641
> URL: https://issues.jboss.org/browse/WFCORE-2641
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management, Security
> Affects Versions: 3.0.0.Beta13
> Reporter: Ondrej Lukas
> Assignee: Darran Lofthouse
> Priority: Blocker
> Fix For: 3.0.0.Beta26
>
>
> When http-interface uses http-authentication-factory attribute for authentication and security-realm attribute for SSL, and referenced security-realm does not include authentication, then authentication through http-interface is not possible.
> When Management Console is used, then page with _The Red Hat JBoss Enterprise Application Platform 7 is running. However you have not yet added any users to be able to access the admin console._ is displayed.
> When https://localhost:9993/management?operation=attribute&name=server-state is accessed then following output is returned:
> {code}
> {
> "outcome" : "failed",
> "failure-description" : "WFLYDMHTTP0006: The security realm is not ready to process requests, see https://localhost:9993/error",
> "rolled-back" : "true"
> }
> {code}
> When security-realm includes also authentication (which is not used) then authentication through http-interface works as expected.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (DROOLS-1621) DMN validation fails when executed on IBM JDK when checking referenced types
by Tibor Zimányi (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1621?page=com.atlassian.jira.plugi... ]
Tibor Zimányi updated DROOLS-1621:
----------------------------------
Description:
When running test method ValidatorTest.testVALIDATION(), the test fails with this output[1]. This is caused by rules _TYPEREF_NOT_FEEL_NOT_DEF_p1_ and _TYPEREF_NOT_FEEL_NOT_DEF_p2_ from _dmn-validation-rules-typeref.drl_ matching during validation and so triggering errors.
It looks like this is caused by different evaluation of constraint _not( ItemDefinition( name == $typeRef ) )_ on IBM JDK. $typeRef is of type QName. It looks like that when running on ORacle JDK, the toString() method of QName is invoked automatically so the ItemDefinition is matched. Otherwise, when running on IBM JDK, the constraint must be changed to _not( ItemDefinition( name == $typeRef.toString() ) )_ so ItemDefinition is matched. I'm not sure if this is really the cause of this problem or just a workaround. The session looks properly populated with facts during validation.
Possible fix that adds toString() to appropriate validation rules can be found here [2].
[1] https://gist.github.com/baldimir/2dbc678886ad30a091a30bdb1d91f4cf
[2] https://github.com/kiegroup/drools/pull/1332
was:
When running test method ValidatorTest.testVALIDATION(), the test fails with this output[1]. This is caused by rules _TYPEREF_NOT_FEEL_NOT_DEF_p1_ and _TYPEREF_NOT_FEEL_NOT_DEF_p2_ from _dmn-validation-rules-typeref.drl_ matching during validation and so triggering errors.
It looks like this is caused by different evaluation of constraint _not( ItemDefinition( name == $typeRef ) )_ on IBM JDK. $typeRef is of type QName. It looks like that when running on ORacle JDK, the toString() method of QName is invoked automatically so the ItemDefinition is matched. Otherwise, when running on IBM JDK, the constraint must be changed to _not( ItemDefinition( name == $typeRef.toString() ) )_ so ItemDefinition is matched. I'm not sure if this is really the cause of this problem or just a workaround. The session looks properly populated with facts during validation.
[1] https://gist.github.com/baldimir/2dbc678886ad30a091a30bdb1d91f4cf
> DMN validation fails when executed on IBM JDK when checking referenced types
> ----------------------------------------------------------------------------
>
> Key: DROOLS-1621
> URL: https://issues.jboss.org/browse/DROOLS-1621
> Project: Drools
> Issue Type: Bug
> Components: dmn engine
> Affects Versions: 7.0.0.Final
> Reporter: Tibor Zimányi
> Assignee: Edson Tirelli
> Labels: reported-by-qe
> Fix For: 7.1.0.Final
>
>
> When running test method ValidatorTest.testVALIDATION(), the test fails with this output[1]. This is caused by rules _TYPEREF_NOT_FEEL_NOT_DEF_p1_ and _TYPEREF_NOT_FEEL_NOT_DEF_p2_ from _dmn-validation-rules-typeref.drl_ matching during validation and so triggering errors.
> It looks like this is caused by different evaluation of constraint _not( ItemDefinition( name == $typeRef ) )_ on IBM JDK. $typeRef is of type QName. It looks like that when running on ORacle JDK, the toString() method of QName is invoked automatically so the ItemDefinition is matched. Otherwise, when running on IBM JDK, the constraint must be changed to _not( ItemDefinition( name == $typeRef.toString() ) )_ so ItemDefinition is matched. I'm not sure if this is really the cause of this problem or just a workaround. The session looks properly populated with facts during validation.
> Possible fix that adds toString() to appropriate validation rules can be found here [2].
> [1] https://gist.github.com/baldimir/2dbc678886ad30a091a30bdb1d91f4cf
> [2] https://github.com/kiegroup/drools/pull/1332
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (DROOLS-1621) DMN validation fails when executed on IBM JDK when checking referenced types
by Tibor Zimányi (JIRA)
Tibor Zimányi created DROOLS-1621:
-------------------------------------
Summary: DMN validation fails when executed on IBM JDK when checking referenced types
Key: DROOLS-1621
URL: https://issues.jboss.org/browse/DROOLS-1621
Project: Drools
Issue Type: Bug
Components: dmn engine
Affects Versions: 7.0.0.Final
Reporter: Tibor Zimányi
Assignee: Edson Tirelli
Fix For: 7.1.0.Final
When running test method ValidatorTest.testVALIDATION(), the test fails with this output[1]. This is caused by rules _TYPEREF_NOT_FEEL_NOT_DEF_p1_ and _TYPEREF_NOT_FEEL_NOT_DEF_p2_ from _dmn-validation-rules-typeref.drl_ matching during validation and so triggering errors.
It looks like this is caused by different evaluation of constraint _not( ItemDefinition( name == $typeRef ) )_ on IBM JDK. $typeRef is of type QName. It looks like that when running on ORacle JDK, the toString() method of QName is invoked automatically so the ItemDefinition is matched. Otherwise, when running on IBM JDK, the constraint must be changed to _not( ItemDefinition( name == $typeRef.toString() ) )_ so ItemDefinition is matched. I'm not sure if this is really the cause of this problem or just a workaround. The session looks properly populated with facts during validation.
[1] https://gist.github.com/baldimir/2dbc678886ad30a091a30bdb1d91f4cf
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (WFLY-8961) Elytron in JMS: Unable to use authenticate with JBOSS-LOCAL-USER
by Jeff Mesnil (JIRA)
[ https://issues.jboss.org/browse/WFLY-8961?page=com.atlassian.jira.plugin.... ]
Jeff Mesnil edited comment on WFLY-8961 at 6/20/17 9:40 AM:
------------------------------------------------------------
[~dmlloyd] that's my understanding too. This issue is an enhancement as we don't support this use case with PicketBox and should not qualify as Critical.
> Elytron in JMS: Unable to use authenticate with JBOSS-LOCAL-USER
> ----------------------------------------------------------------
>
> Key: WFLY-8961
> URL: https://issues.jboss.org/browse/WFLY-8961
> Project: WildFly
> Issue Type: Bug
> Components: JMS, Security
> Reporter: Josef Cacek
> Assignee: Jeff Mesnil
> Priority: Critical
> Labels: eap7.1.0-to-prd
>
> I'm not able to authenticate to JMS when using JBOSS-LOCAL-USER SASL mechanism. {{ConnectionFactory.createContext()}} call and the client call fails with:
> {noformat}
> javax.jms.JMSSecurityRuntimeException: AMQ119031: Unable to validate user
> {noformat}
> This issue is similar to JBEAP-10527, but for JBOSS-LOCAL-USER mechanism (compared to DIGEST-MD5 for instance) we don't have a username or password. This problem can be in other SASL mechanisms too (e.g. EXTERNAL - where we authenticate a user with client certificate).
> Code used for testing:
> {code:java}
> AuthenticationContext.empty()
> .with(MatchRule.ALL,
> AuthenticationConfiguration.empty().useProvidersFromClassLoader(getClass().getClassLoader())
> .setSaslMechanismSelector(SaslMechanismSelector.fromString("JBOSS-LOCAL-USER")))
> .run(() -> {
> try {
> // ... initialize naming etc. here
> ConnectionFactory connectionFactory = (ConnectionFactory) namingContext
> .lookup("jms/RemoteConnectionFactory");
> JMSContext context = connectionFactory.createContext();
> } catch (NamingException e) {
> // ...
> }
> });
> {code}
> Server log contains:
> {noformat}
> 2017-06-08 15:00:07,076 TRACE [org.wildfly.security] (default I/O-4) Handling MechanismInformationCallback type='SASL' name='JBOSS-LOCAL-USER' host-name='localhost' protocol='remote'
> 2017-06-08 15:00:07,077 TRACE [org.wildfly.security] (default I/O-4) Handling MechanismInformationCallback type='SASL' name='JBOSS-LOCAL-USER' host-name='localhost' protocol='remote'
> 2017-06-08 15:00:07,077 TRACE [org.wildfly.security] (default I/O-4) Created SaslServer [org.wildfly.security.sasl.util.SecurityIdentitySaslServerFactory$1@55b75111] for mechanism [JBOSS-LOCAL-USER]
> 2017-06-08 15:00:07,083 TRACE [org.wildfly.security] (default task-2) Handling NameCallback: authenticationName = $local
> 2017-06-08 15:00:07,083 TRACE [org.wildfly.security] (default task-2) Principal assigning: [$local], pre-realm rewritten: [$local], realm name: [local], post-realm rewritten: [$local], realm rewritten: [$local]
> 2017-06-08 15:00:07,084 TRACE [org.wildfly.security] (default task-2) Role mapping: principal [$local] -> decoded roles [] -> realm mapped roles [] -> domain mapped roles [guest]
> 2017-06-08 15:00:07,084 TRACE [org.wildfly.security] (default task-2) Authorizing principal $local.
> 2017-06-08 15:00:07,084 TRACE [org.wildfly.security] (default task-2) Authorizing against the following attributes: [] => []
> 2017-06-08 15:00:07,084 TRACE [org.wildfly.security] (default task-2) Permission mapping: identity [$local] with roles [guest] implies ("org.wildfly.security.auth.permission.LoginPermission" "") = true
> 2017-06-08 15:00:07,095 TRACE [org.wildfly.security] (default task-2) Authorization succeed
> 2017-06-08 15:00:07,095 TRACE [org.wildfly.security] (default task-2) RunAs authorization succeed - the same identity
> 2017-06-08 15:00:07,095 TRACE [org.wildfly.security] (default task-2) Handling AuthorizeCallback: authenticationID = $local authorizationID = $local authorized = true
> 2017-06-08 15:00:07,095 TRACE [org.wildfly.security] (default task-2) Handling AuthenticationCompleteCallback: succeed
> 2017-06-08 15:00:07,099 TRACE [org.wildfly.security] (default task-2) Handling SecurityIdentityCallback: identity = SecurityIdentity{principal=$local, securityDomain=org.wildfly.security.auth.server.SecurityDomain@24c5501a, authorizationIdentity=EMPTY, realmInfo=RealmInfo{name='local', securityRealm=org.wildfly.security.auth.realm.SimpleMapBackedSecurityRealm@426b003b}, creationTime=2017-06-08T13:00:07.083Z}
> 2017-06-08 15:00:07,142 INFO [org.wildfly.naming] (default task-4) WildFly Naming version 1.0.0.Beta16
> 2017-06-08 15:00:07,908 TRACE [org.wildfly.security] (default I/O-3) Permission mapping: identity [anonymous] with roles [guest] implies ("org.wildfly.security.auth.permission.LoginPermission" "") = false
> 2017-06-08 15:00:07,920 DEBUG [org.apache.activemq.artemis.core.postoffice.impl.PostOfficeImpl] (default I/O-3) Couldn't find any bindings for address=activemq.notifications on message=ServerMessage[messageID=25,durable=true,userID=null,priority=0, bodySize=512, timestamp=0,expiration=0, durable=true, address=activemq.notifications,properties=TypedProperties[_AMQ_NotifType=SECURITY_AUTHENTICATION_VIOLATION,_AMQ_NotifTimestamp=1496926807920]]@1825253250
> 2017-06-08 15:00:07,920 DEBUG [org.apache.activemq.artemis.core.postoffice.impl.PostOfficeImpl] (default I/O-3) Message ServerMessage[messageID=25,durable=true,userID=null,priority=0, bodySize=512, timestamp=0,expiration=0, durable=true, address=activemq.notifications,properties=TypedProperties[_AMQ_NotifType=SECURITY_AUTHENTICATION_VIOLATION,_AMQ_NotifTimestamp=1496926807920]]@1825253250 is not going anywhere as it didn't have a binding on address:activemq.notifications
> 2017-06-08 15:00:07,924 ERROR [org.apache.activemq.artemis.core.server] (default I/O-3) AMQ224018: Failed to create session: ActiveMQSecurityException[errorType=SECURITY_EXCEPTION message=AMQ119031: Unable to validate user]
> at org.apache.activemq.artemis.core.security.impl.SecurityStoreImpl.authenticate(SecurityStoreImpl.java:144)
> at org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.createSession(ActiveMQServerImpl.java:1283)
> at org.apache.activemq.artemis.core.protocol.core.impl.ActiveMQPacketHandler.handleCreateSession(ActiveMQPacketHandler.java:156)
> at org.apache.activemq.artemis.core.protocol.core.impl.ActiveMQPacketHandler.handlePacket(ActiveMQPacketHandler.java:81)
> at org.apache.activemq.artemis.core.protocol.core.impl.ChannelImpl.handlePacket(ChannelImpl.java:623)
> at org.apache.activemq.artemis.core.protocol.core.impl.RemotingConnectionImpl.doBufferReceived(RemotingConnectionImpl.java:379)
> at org.apache.activemq.artemis.core.protocol.core.impl.RemotingConnectionImpl.bufferReceived(RemotingConnectionImpl.java:362)
> at org.apache.activemq.artemis.core.remoting.server.impl.RemotingServiceImpl$DelegatingBufferHandler.bufferReceived(RemotingServiceImpl.java:621)
> at org.apache.activemq.artemis.core.remoting.impl.netty.ActiveMQChannelHandler.channelRead(ActiveMQChannelHandler.java:69)
> at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:362)
> at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:348)
> at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:340)
> at io.netty.handler.codec.ByteToMessageDecoder.fireChannelRead(ByteToMessageDecoder.java:293)
> at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:267)
> at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:362)
> at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:348)
> at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:340)
> at io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1334)
> at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:362)
> at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:348)
> at io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:926)
> at org.xnio.netty.transport.AbstractXnioSocketChannel$ReadListener.handleEvent(AbstractXnioSocketChannel.java:443)
> at org.xnio.netty.transport.AbstractXnioSocketChannel$ReadListener.handleEvent(AbstractXnioSocketChannel.java:379)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
> at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66)
> at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:89)
> at org.xnio.nio.WorkerThread.run(WorkerThread.java:571)
> {noformat}
> [~dlofthouse], [~jmesnil], Is there another way to use these SASL mechanisms (without username and password) to create JMSContext? If not then we should change priority to blocker.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (WFCORE-2985) ProcessWrapper.waitForClose shouldn't close the output stream
by Jean-Francois Denise (JIRA)
Jean-Francois Denise created WFCORE-2985:
--------------------------------------------
Summary: ProcessWrapper.waitForClose shouldn't close the output stream
Key: WFCORE-2985
URL: https://issues.jboss.org/browse/WFCORE-2985
Project: WildFly Core
Issue Type: Bug
Components: CLI, Test Suite
Reporter: Jean-Francois Denise
Assignee: Jean-Francois Denise
When the output stream is closed, if aesh is reading on the other side of the stream inside the CLI process, this could make the CLI process to exit. That is occurring systematically with aesh-readline.
ProcessWrapper.waitForClose is called in the following cases:
- ctrlCAndWaitForClose: The test expects that Ctrl-C will make the process to exit.
- pushLineAndWaitForClose: The test expects that the passed command will make the process to exit (e.g.: quit)
- executeNonInteractive: The test expects that the CLI process will exit by itself, no aesh console started (file or command options). In this case, closing the output stream shouldn't hide any issue. But it shouldn't be required either.
If closing the output stream makes the CLI process to exit it could hide potential CLI issues.
I suggest that we remove the output stream.close once we have switched to use aesh-readline and see on all platforms how tests are going to behave. We could have exotic platforms that don't make the process to exit properly if output is not closed. We will have to handle them specificaly.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (ELY-1239) Elytron client, elytron-1_0.xsd, protection-parameter-credentials is incorrectly defined as client-credentials-type.
by Peter Skopek (JIRA)
[ https://issues.jboss.org/browse/ELY-1239?page=com.atlassian.jira.plugin.s... ]
Peter Skopek commented on ELY-1239:
-----------------------------------
I have retained clear-password element despite it has alternative in credential-store-reference, but there might be already some client configurations using it.
> Elytron client, elytron-1_0.xsd, protection-parameter-credentials is incorrectly defined as client-credentials-type.
> --------------------------------------------------------------------------------------------------------------------
>
> Key: ELY-1239
> URL: https://issues.jboss.org/browse/ELY-1239
> Project: WildFly Elytron
> Issue Type: Bug
> Components: Authentication Client, Credential Store
> Reporter: Hynek Švábek
> Assignee: Darran Lofthouse
> Priority: Blocker
>
> Elytron client, elytron-1_0.xsd, *protection-parameter-credentials* is incorrectly defined as client-credentials-type [1].
> For *protection-parameter-credentials* is valid only credential-store-reference element:
> {code}
> <xsd:element name="credential-store-reference" type="credential-store-reference-type"/>
> {code}
> But now is *protection-parameter-credentials* defined as type *client-credentials-type* [1] which can have these values:
> {code}
> <xsd:complexType name="client-credentials-type">
> <xsd:choice minOccurs="0" maxOccurs="unbounded">
> <xsd:element name="key-store-reference" type="key-store-ref-type"/>
> <xsd:element name="credential-store-reference" type="credential-store-reference-type"/>
> <xsd:element name="clear-password" type="clear-password-type"/>
> <xsd:element name="hashed-password" type="hashed-password-type"/>
> <xsd:element name="crypt-password" type="crypt-password-type"/>
> <xsd:element name="key-pair" type="key-pair-type"/>
> <xsd:element name="certificate" type="certificate-type"/>
> <xsd:element name="public-key-pem" type="xsd:string"/>
> <xsd:element name="bearer-token" type="bearer-token-type"/>
> <xsd:element name="oauth2-bearer-token" type="oauth2-bearer-token-type"/>
> </xsd:choice>
> </xsd:complexType>
> {code}
> Please keep on mind that changes must be done accordingly in ElytronXMLParser too.
> [1] https://github.com/wildfly-security/wildfly-elytron/blob/1.1.0.Beta47/src...
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (ELY-1239) Elytron client, elytron-1_0.xsd, protection-parameter-credentials is incorrectly defined as client-credentials-type.
by Peter Skopek (JIRA)
[ https://issues.jboss.org/browse/ELY-1239?page=com.atlassian.jira.plugin.s... ]
Peter Skopek reassigned ELY-1239:
---------------------------------
Assignee: Peter Skopek (was: Darran Lofthouse)
> Elytron client, elytron-1_0.xsd, protection-parameter-credentials is incorrectly defined as client-credentials-type.
> --------------------------------------------------------------------------------------------------------------------
>
> Key: ELY-1239
> URL: https://issues.jboss.org/browse/ELY-1239
> Project: WildFly Elytron
> Issue Type: Bug
> Components: Authentication Client, Credential Store
> Reporter: Hynek Švábek
> Assignee: Peter Skopek
> Priority: Blocker
>
> Elytron client, elytron-1_0.xsd, *protection-parameter-credentials* is incorrectly defined as client-credentials-type [1].
> For *protection-parameter-credentials* is valid only credential-store-reference element:
> {code}
> <xsd:element name="credential-store-reference" type="credential-store-reference-type"/>
> {code}
> But now is *protection-parameter-credentials* defined as type *client-credentials-type* [1] which can have these values:
> {code}
> <xsd:complexType name="client-credentials-type">
> <xsd:choice minOccurs="0" maxOccurs="unbounded">
> <xsd:element name="key-store-reference" type="key-store-ref-type"/>
> <xsd:element name="credential-store-reference" type="credential-store-reference-type"/>
> <xsd:element name="clear-password" type="clear-password-type"/>
> <xsd:element name="hashed-password" type="hashed-password-type"/>
> <xsd:element name="crypt-password" type="crypt-password-type"/>
> <xsd:element name="key-pair" type="key-pair-type"/>
> <xsd:element name="certificate" type="certificate-type"/>
> <xsd:element name="public-key-pem" type="xsd:string"/>
> <xsd:element name="bearer-token" type="bearer-token-type"/>
> <xsd:element name="oauth2-bearer-token" type="oauth2-bearer-token-type"/>
> </xsd:choice>
> </xsd:complexType>
> {code}
> Please keep on mind that changes must be done accordingly in ElytronXMLParser too.
> [1] https://github.com/wildfly-security/wildfly-elytron/blob/1.1.0.Beta47/src...
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (WFCORE-2766) Application server must be reloaded when is updated credential reference of credential store. There isn't any information that it needs reload.
by Yeray Borges (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2766?page=com.atlassian.jira.plugi... ]
Yeray Borges resolved WFCORE-2766.
----------------------------------
Fix Version/s: 3.0.0.Beta27
Resolution: Done
Changed as solved because related issues were already solved
> Application server must be reloaded when is updated credential reference of credential store. There isn't any information that it needs reload.
> -----------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-2766
> URL: https://issues.jboss.org/browse/WFCORE-2766
> Project: WildFly Core
> Issue Type: Bug
> Components: Security
> Reporter: Hynek Švábek
> Assignee: Yeray Borges
> Fix For: 3.0.0.Beta27
>
>
> Application server must be reloaded when is updated credential reference of credential store. There isn't any information that it needs reload.
> In model is "restart-required" => "no-services" and credential-reference update operation ends with success message without any information about reload.
> {code:collapse}
> "credential-reference" => {
> "type" => OBJECT,
> "description" => "Credential reference to be used to create protection parameter.",
> "expressions-allowed" => false,
> "required" => true,
> "nillable" => false,
> "access-constraints" => {"sensitive" => {"credential" => {"type" => "core"}}},
> "value-type" => {
> "store" => {
> "type" => STRING,
> "description" => "The name of the credential store holding the alias to credential.",
> "expressions-allowed" => false,
> "required" => false,
> "nillable" => true,
> "capability-reference" => "org.wildfly.security.credential-store",
> "min-length" => 1L,
> "max-length" => 2147483647L
> },
> "alias" => {
> "type" => STRING,
> "description" => "The alias which denotes stored secret or credential in the store.",
> "expressions-allowed" => true,
> "required" => false,
> "nillable" => true,
> "min-length" => 1L,
> "max-length" => 2147483647L
> },
> "type" => {
> "type" => STRING,
> "description" => "The type of credential this reference is denoting.",
> "expressions-allowed" => true,
> "required" => false,
> "nillable" => true,
> "min-length" => 1L,
> "max-length" => 2147483647L
> },
> "clear-text" => {
> "type" => STRING,
> "description" => "Secret specified using clear text. Check credential store way of supplying credential/secrets to services.",
> "expressions-allowed" => true,
> "required" => false,
> "nillable" => true,
> "min-length" => 1L,
> "max-length" => 2147483647L
> }
> },
> "access-type" => "read-write",
> "storage" => "configuration",
> "restart-required" => "no-services"
> },
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months