[JBoss JIRA] (WFLY-7158) Working with multiple keys in key store
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/WFLY-7158?page=com.atlassian.jira.plugin.... ]
Jan Kalina edited comment on WFLY-7158 at 2/15/17 9:09 AM:
-----------------------------------------------------------
*Current status:* key-manager reference key-store to obtain SSL key, credential-reference is used only to obtain its password
*Required status:* key-manager use credential-reference to obtain SSL key
was (Author: honza889):
Current status: key-manager reference key-store to obtain SSL key, credential-reference is used only to obtain its password
Required status: key-manager use credential-reference to obtain SSL key
> Working with multiple keys in key store
> ---------------------------------------
>
> Key: WFLY-7158
> URL: https://issues.jboss.org/browse/WFLY-7158
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Reporter: Martin Choma
> Assignee: Jan Kalina
> Priority: Critical
> Fix For: 11.0.0.Alpha1
>
>
> In case when 2 keys are present in keystore, then alias-filter (filtering into single key) on key-store resource has to be specified, otherwise key-manager can't be created. If user want to use keystore with multiple keys, user has to configure multiple key-store elements with specified alias-filter (filtering into single key).
> That is pretty inconvinient. Probably introducing *alias attribute on key-manager* would be more intuitive solution to this situation.
> {code}
> /subsystem=elytron/key-managers=server:add(key-store=server,algorithm="SunX509",password=key-password)
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (WFLY-7158) Working with multiple keys in key store
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/WFLY-7158?page=com.atlassian.jira.plugin.... ]
Jan Kalina commented on WFLY-7158:
----------------------------------
Current status: key-manager reference key-store to obtain SSL key, credential-reference is used only to obtain its password
Required status: key-manager use credential-reference to obtain SSL key
> Working with multiple keys in key store
> ---------------------------------------
>
> Key: WFLY-7158
> URL: https://issues.jboss.org/browse/WFLY-7158
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Reporter: Martin Choma
> Assignee: Jan Kalina
> Priority: Critical
> Fix For: 11.0.0.Alpha1
>
>
> In case when 2 keys are present in keystore, then alias-filter (filtering into single key) on key-store resource has to be specified, otherwise key-manager can't be created. If user want to use keystore with multiple keys, user has to configure multiple key-store elements with specified alias-filter (filtering into single key).
> That is pretty inconvinient. Probably introducing *alias attribute on key-manager* would be more intuitive solution to this situation.
> {code}
> /subsystem=elytron/key-managers=server:add(key-store=server,algorithm="SunX509",password=key-password)
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (WFLY-8128) recovery-credential under xa-data-source is missing support for credential store references
by Stefano Maestri (JIRA)
[ https://issues.jboss.org/browse/WFLY-8128?page=com.atlassian.jira.plugin.... ]
Stefano Maestri moved JBEAP-8859 to WFLY-8128:
----------------------------------------------
Project: WildFly (was: JBoss Enterprise Application Platform)
Key: WFLY-8128 (was: JBEAP-8859)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: JCA
Security
(was: JCA)
(was: Security)
Affects Version/s: (was: 7.1.0.DR11)
> recovery-credential under xa-data-source is missing support for credential store references
> -------------------------------------------------------------------------------------------
>
> Key: WFLY-8128
> URL: https://issues.jboss.org/browse/WFLY-8128
> Project: WildFly
> Issue Type: Bug
> Components: JCA, Security
> Reporter: Stefano Maestri
> Assignee: Stefano Maestri
> Priority: Blocker
> Labels: credential-store, jca
>
> {{recovery-credential}} is missing support for {{credential-reference}}
> {code:xml}
> <xa-datasource jndi-name="java:jboss/xa-datasources/test" pool-name="test">
> <xa-datasource-property name="test">
> aa
> </xa-datasource-property>
> <xa-datasource-property name="test2">
> aa
> </xa-datasource-property>
> <driver>h2</driver>
> <security>
> <user-name>sa</user-name>
> <credential-reference clear-text="password" />
> </security>
> <recovery>
> <recover-credential>
> <user-name>user</user-name>
> <password>pass</password>
> </recover-credential>
> </recovery>
> </xa-datasource>
> {code}
> {noformat}
> [standalone@embedded /] /subsystem=datasources/xa-data-source=test:write-attribute(name=recovery-username, value=user
> [standalone@embedded /] /subsystem=datasources/xa-data-source=test:write-attribute(name=recovery-password, value=pass
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (WFLY-8125) Programatically set Elytron AuthenticationContext does not work in application server modules
by Ondrej Lukas (JIRA)
Ondrej Lukas created WFLY-8125:
----------------------------------
Summary: Programatically set Elytron AuthenticationContext does not work in application server modules
Key: WFLY-8125
URL: https://issues.jboss.org/browse/WFLY-8125
Project: WildFly
Issue Type: Bug
Components: Security
Reporter: Ondrej Lukas
Assignee: Darran Lofthouse
Priority: Blocker
Attachments: module-without-wildfly-config-xml-dep.war, module-without-wildfly-config-xml.jar
In case when code inside of any module in aplication server executes management operation through programatically configured AuthenticationContext then it is not work correctly.
According to server log it seems that for some reason it at the first authenticate correctly through programatically configured AuthenticationContext, but then it try to reauthenticate through AuthenticationContext obtained from application server (if default-authentication-context is set then it is used; otherwise reauthenticate fails completetly).
The same type of behavior occurs also when {{wildfly.config.url}} property is used.
Request blocker flag because this issue breaks RFE.
Server log (when default-authentication-context is set, see Steps to Reproduce):
{code}
2017-02-15 13:43:30,584 TRACE [org.wildfly.security] (default task-2) getAuthenticationConfiguration uri=remote+http://localhost:9990, protocolDefaultPort=-1, abstractType=null, abstractTypeAuthority=null, purpose=null, MatchRule=[no user,host=localhost], AuthenticationConfiguration=[TrustManager,NamePrincipal=user2,Credentials,realm=ManagementRealm,host=localhost,port=9990]
2017-02-15 13:43:30,585 TRACE [org.wildfly.security] (default task-2) getAuthenticationConfiguration uri=remote+http://localhost:9990, protocolDefaultPort=-1, abstractType=null, abstractTypeAuthority=null, purpose=connect, MatchRule=[no user], AuthenticationConfiguration=[TrustManager,NamePrincipal=user2,Credentials,realm=ManagementRealm,host=localhost,port=9990]
2017-02-15 13:43:30,596 TRACE [org.wildfly.security] (management I/O-2) Handling MechanismInformationCallback
2017-02-15 13:43:30,597 TRACE [org.wildfly.security] (management I/O-2) Handling MechanismInformationCallback
2017-02-15 13:43:30,598 TRACE [org.wildfly.security] (management I/O-2) Handling AvailableRealmsCallback: realms = [ManagementRealm]
2017-02-15 13:43:30,607 TRACE [org.wildfly.security] (management task-10) Handling RealmCallback: selected = [ManagementRealm]
2017-02-15 13:43:30,608 TRACE [org.wildfly.security] (management task-10) Handling NameCallback: authenticationName = user2
2017-02-15 13:43:30,610 TRACE [org.wildfly.security] (management task-10) Principal assigning: [user2], pre-realm rewritten: [user2], realm name: [ManagementRealm], post realm rewritten: [user2], realm rewritten: [user2]
2017-02-15 13:43:30,614 TRACE [org.wildfly.security] (management task-10) Handling CredentialCallback: obtained successfully
2017-02-15 13:43:30,615 TRACE [org.wildfly.security] (management task-10) Role mapping: principal [user2] -> decoded roles [] -> realm mapped roles [] -> domain mapped roles []
2017-02-15 13:43:30,616 TRACE [org.wildfly.security] (management task-10) Authorizing principal user2.
2017-02-15 13:43:30,616 TRACE [org.wildfly.security] (management task-10) Authorizing against the following attributes: [groups] => []
2017-02-15 13:43:30,617 TRACE [org.wildfly.security] (management task-10) Permission mapping: identity [user2] with roles [] implies ("org.wildfly.security.auth.permission.LoginPermission" "") = true
2017-02-15 13:43:30,617 TRACE [org.wildfly.security] (management task-10) Authorization succeed
2017-02-15 13:43:30,617 TRACE [org.wildfly.security] (management task-10) RunAs authorization succeed - the same identity
2017-02-15 13:43:30,617 TRACE [org.wildfly.security] (management task-10) Handling AuthorizeCallback: authenticationID = user2 authorizationID = user2 authorized = true
2017-02-15 13:43:30,618 TRACE [org.wildfly.security] (management task-10) Handling AuthenticationCompleteCallback: succeed
2017-02-15 13:43:30,618 TRACE [org.wildfly.security] (management task-10) Handling SecurityIdentityCallback: identity = org.wildfly.security.auth.server.SecurityIdentity@9b7d11
2017-02-15 13:43:30,640 TRACE [org.wildfly.security] (default task-2) getAuthenticationConfiguration uri=remote+http://localhost:9990, protocolDefaultPort=-1, abstractType=null, abstractTypeAuthority=null, purpose=null, MatchRule=[no user,host=localhost], AuthenticationConfiguration=[TrustManager,NamePrincipal=user1,realm=ManagementRealm,FilterSaslMechanism allow=true,name=[ DIGEST-MD5 ],Credentials,host=localhost,port=9990]
2017-02-15 13:43:30,641 TRACE [org.wildfly.security] (default task-2) getAuthenticationConfiguration uri=remote+http://localhost:9990, protocolDefaultPort=-1, abstractType=null, abstractTypeAuthority=null, purpose=connect, MatchRule=[no user], AuthenticationConfiguration=[TrustManager,NamePrincipal=user1,realm=ManagementRealm,FilterSaslMechanism allow=true,name=[ DIGEST-MD5 ],Credentials,host=localhost,port=9990]
2017-02-15 13:43:30,652 TRACE [org.wildfly.security] (management I/O-1) Handling MechanismInformationCallback
2017-02-15 13:43:30,653 TRACE [org.wildfly.security] (management I/O-1) Handling MechanismInformationCallback
2017-02-15 13:43:30,653 TRACE [org.wildfly.security] (management I/O-1) Handling AvailableRealmsCallback: realms = [ManagementRealm]
2017-02-15 13:43:30,656 TRACE [org.wildfly.security] (management task-6) Handling RealmCallback: selected = [ManagementRealm]
2017-02-15 13:43:30,656 TRACE [org.wildfly.security] (management task-6) Handling NameCallback: authenticationName = user1
2017-02-15 13:43:30,656 TRACE [org.wildfly.security] (management task-6) Principal assigning: [user1], pre-realm rewritten: [user1], realm name: [ManagementRealm], post realm rewritten: [user1], realm rewritten: [user1]
2017-02-15 13:43:30,656 TRACE [org.wildfly.security] (management task-6) Handling CredentialCallback: obtained successfully
2017-02-15 13:43:30,657 TRACE [org.wildfly.security] (management task-6) Role mapping: principal [user1] -> decoded roles [] -> realm mapped roles [] -> domain mapped roles []
2017-02-15 13:43:30,657 TRACE [org.wildfly.security] (management task-6) Authorizing principal user1.
2017-02-15 13:43:30,657 TRACE [org.wildfly.security] (management task-6) Authorizing against the following attributes: [groups] => []
2017-02-15 13:43:30,657 TRACE [org.wildfly.security] (management task-6) Permission mapping: identity [user1] with roles [] implies ("org.wildfly.security.auth.permission.LoginPermission" "") = true
2017-02-15 13:43:30,657 TRACE [org.wildfly.security] (management task-6) Authorization succeed
2017-02-15 13:43:30,657 TRACE [org.wildfly.security] (management task-6) RunAs authorization succeed - the same identity
2017-02-15 13:43:30,657 TRACE [org.wildfly.security] (management task-6) Handling AuthorizeCallback: authenticationID = user1 authorizationID = user1 authorized = true
2017-02-15 13:43:30,657 TRACE [org.wildfly.security] (management task-6) Handling AuthenticationCompleteCallback: succeed
2017-02-15 13:43:30,658 TRACE [org.wildfly.security] (management task-6) Handling SecurityIdentityCallback: identity = org.wildfly.security.auth.server.SecurityIdentity@53367941
{code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (WFLY-8125) Programatically set Elytron AuthenticationContext does not work in application server modules
by Ondrej Lukas (JIRA)
[ https://issues.jboss.org/browse/WFLY-8125?page=com.atlassian.jira.plugin.... ]
Ondrej Lukas updated WFLY-8125:
-------------------------------
Attachment: module-without-wildfly-config-xml.jar
module-without-wildfly-config-xml-dep.war
> Programatically set Elytron AuthenticationContext does not work in application server modules
> ---------------------------------------------------------------------------------------------
>
> Key: WFLY-8125
> URL: https://issues.jboss.org/browse/WFLY-8125
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Reporter: Ondrej Lukas
> Assignee: Darran Lofthouse
> Priority: Blocker
> Attachments: module-without-wildfly-config-xml-dep.war, module-without-wildfly-config-xml.jar
>
>
> In case when code inside of any module in aplication server executes management operation through programatically configured AuthenticationContext then it is not work correctly.
> According to server log it seems that for some reason it at the first authenticate correctly through programatically configured AuthenticationContext, but then it try to reauthenticate through AuthenticationContext obtained from application server (if default-authentication-context is set then it is used; otherwise reauthenticate fails completetly).
> The same type of behavior occurs also when {{wildfly.config.url}} property is used.
> Request blocker flag because this issue breaks RFE.
> Server log (when default-authentication-context is set, see Steps to Reproduce):
> {code}
> 2017-02-15 13:43:30,584 TRACE [org.wildfly.security] (default task-2) getAuthenticationConfiguration uri=remote+http://localhost:9990, protocolDefaultPort=-1, abstractType=null, abstractTypeAuthority=null, purpose=null, MatchRule=[no user,host=localhost], AuthenticationConfiguration=[TrustManager,NamePrincipal=user2,Credentials,realm=ManagementRealm,host=localhost,port=9990]
> 2017-02-15 13:43:30,585 TRACE [org.wildfly.security] (default task-2) getAuthenticationConfiguration uri=remote+http://localhost:9990, protocolDefaultPort=-1, abstractType=null, abstractTypeAuthority=null, purpose=connect, MatchRule=[no user], AuthenticationConfiguration=[TrustManager,NamePrincipal=user2,Credentials,realm=ManagementRealm,host=localhost,port=9990]
> 2017-02-15 13:43:30,596 TRACE [org.wildfly.security] (management I/O-2) Handling MechanismInformationCallback
> 2017-02-15 13:43:30,597 TRACE [org.wildfly.security] (management I/O-2) Handling MechanismInformationCallback
> 2017-02-15 13:43:30,598 TRACE [org.wildfly.security] (management I/O-2) Handling AvailableRealmsCallback: realms = [ManagementRealm]
> 2017-02-15 13:43:30,607 TRACE [org.wildfly.security] (management task-10) Handling RealmCallback: selected = [ManagementRealm]
> 2017-02-15 13:43:30,608 TRACE [org.wildfly.security] (management task-10) Handling NameCallback: authenticationName = user2
> 2017-02-15 13:43:30,610 TRACE [org.wildfly.security] (management task-10) Principal assigning: [user2], pre-realm rewritten: [user2], realm name: [ManagementRealm], post realm rewritten: [user2], realm rewritten: [user2]
> 2017-02-15 13:43:30,614 TRACE [org.wildfly.security] (management task-10) Handling CredentialCallback: obtained successfully
> 2017-02-15 13:43:30,615 TRACE [org.wildfly.security] (management task-10) Role mapping: principal [user2] -> decoded roles [] -> realm mapped roles [] -> domain mapped roles []
> 2017-02-15 13:43:30,616 TRACE [org.wildfly.security] (management task-10) Authorizing principal user2.
> 2017-02-15 13:43:30,616 TRACE [org.wildfly.security] (management task-10) Authorizing against the following attributes: [groups] => []
> 2017-02-15 13:43:30,617 TRACE [org.wildfly.security] (management task-10) Permission mapping: identity [user2] with roles [] implies ("org.wildfly.security.auth.permission.LoginPermission" "") = true
> 2017-02-15 13:43:30,617 TRACE [org.wildfly.security] (management task-10) Authorization succeed
> 2017-02-15 13:43:30,617 TRACE [org.wildfly.security] (management task-10) RunAs authorization succeed - the same identity
> 2017-02-15 13:43:30,617 TRACE [org.wildfly.security] (management task-10) Handling AuthorizeCallback: authenticationID = user2 authorizationID = user2 authorized = true
> 2017-02-15 13:43:30,618 TRACE [org.wildfly.security] (management task-10) Handling AuthenticationCompleteCallback: succeed
> 2017-02-15 13:43:30,618 TRACE [org.wildfly.security] (management task-10) Handling SecurityIdentityCallback: identity = org.wildfly.security.auth.server.SecurityIdentity@9b7d11
> 2017-02-15 13:43:30,640 TRACE [org.wildfly.security] (default task-2) getAuthenticationConfiguration uri=remote+http://localhost:9990, protocolDefaultPort=-1, abstractType=null, abstractTypeAuthority=null, purpose=null, MatchRule=[no user,host=localhost], AuthenticationConfiguration=[TrustManager,NamePrincipal=user1,realm=ManagementRealm,FilterSaslMechanism allow=true,name=[ DIGEST-MD5 ],Credentials,host=localhost,port=9990]
> 2017-02-15 13:43:30,641 TRACE [org.wildfly.security] (default task-2) getAuthenticationConfiguration uri=remote+http://localhost:9990, protocolDefaultPort=-1, abstractType=null, abstractTypeAuthority=null, purpose=connect, MatchRule=[no user], AuthenticationConfiguration=[TrustManager,NamePrincipal=user1,realm=ManagementRealm,FilterSaslMechanism allow=true,name=[ DIGEST-MD5 ],Credentials,host=localhost,port=9990]
> 2017-02-15 13:43:30,652 TRACE [org.wildfly.security] (management I/O-1) Handling MechanismInformationCallback
> 2017-02-15 13:43:30,653 TRACE [org.wildfly.security] (management I/O-1) Handling MechanismInformationCallback
> 2017-02-15 13:43:30,653 TRACE [org.wildfly.security] (management I/O-1) Handling AvailableRealmsCallback: realms = [ManagementRealm]
> 2017-02-15 13:43:30,656 TRACE [org.wildfly.security] (management task-6) Handling RealmCallback: selected = [ManagementRealm]
> 2017-02-15 13:43:30,656 TRACE [org.wildfly.security] (management task-6) Handling NameCallback: authenticationName = user1
> 2017-02-15 13:43:30,656 TRACE [org.wildfly.security] (management task-6) Principal assigning: [user1], pre-realm rewritten: [user1], realm name: [ManagementRealm], post realm rewritten: [user1], realm rewritten: [user1]
> 2017-02-15 13:43:30,656 TRACE [org.wildfly.security] (management task-6) Handling CredentialCallback: obtained successfully
> 2017-02-15 13:43:30,657 TRACE [org.wildfly.security] (management task-6) Role mapping: principal [user1] -> decoded roles [] -> realm mapped roles [] -> domain mapped roles []
> 2017-02-15 13:43:30,657 TRACE [org.wildfly.security] (management task-6) Authorizing principal user1.
> 2017-02-15 13:43:30,657 TRACE [org.wildfly.security] (management task-6) Authorizing against the following attributes: [groups] => []
> 2017-02-15 13:43:30,657 TRACE [org.wildfly.security] (management task-6) Permission mapping: identity [user1] with roles [] implies ("org.wildfly.security.auth.permission.LoginPermission" "") = true
> 2017-02-15 13:43:30,657 TRACE [org.wildfly.security] (management task-6) Authorization succeed
> 2017-02-15 13:43:30,657 TRACE [org.wildfly.security] (management task-6) RunAs authorization succeed - the same identity
> 2017-02-15 13:43:30,657 TRACE [org.wildfly.security] (management task-6) Handling AuthorizeCallback: authenticationID = user1 authorizationID = user1 authorized = true
> 2017-02-15 13:43:30,657 TRACE [org.wildfly.security] (management task-6) Handling AuthenticationCompleteCallback: succeed
> 2017-02-15 13:43:30,658 TRACE [org.wildfly.security] (management task-6) Handling SecurityIdentityCallback: identity = org.wildfly.security.auth.server.SecurityIdentity@53367941
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months