[JBoss JIRA] (ELY-881) LdapRealm - wrong behavior of {0} wildcard on role-recursion
by Jan Kalina (JIRA)
Jan Kalina created ELY-881:
------------------------------
Summary: LdapRealm - wrong behavior of {0} wildcard on role-recursion
Key: ELY-881
URL: https://issues.jboss.org/browse/ELY-881
Project: WildFly Elytron
Issue Type: Bug
Components: Realms
Affects Versions: 1.1.0.Beta19
Reporter: Jan Kalina
Assignee: Jan Kalina
Wildcard "{0}" is replaced by username in filter-name in filtering attribute mapping.
It is correct for search of identity roles, but wrong for search roles of role - on role-recursion. In such case it should be replaced by name of that role.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (ELY-881) LdapRealm - wrong behavior of {0} wildcard on role-recursion
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/ELY-881?page=com.atlassian.jira.plugin.sy... ]
Jan Kalina updated ELY-881:
---------------------------
Description:
Wildcard "\{0\}" is replaced by username in filter-name in filtering attribute mapping.
It is correct for search of identity roles, but wrong for search roles of role - on role-recursion. In such case it should be replaced by name of that role.
was:
Wildcard "{0}" is replaced by username in filter-name in filtering attribute mapping.
It is correct for search of identity roles, but wrong for search roles of role - on role-recursion. In such case it should be replaced by name of that role.
> LdapRealm - wrong behavior of {0} wildcard on role-recursion
> ------------------------------------------------------------
>
> Key: ELY-881
> URL: https://issues.jboss.org/browse/ELY-881
> Project: WildFly Elytron
> Issue Type: Bug
> Components: Realms
> Affects Versions: 1.1.0.Beta19
> Reporter: Jan Kalina
> Assignee: Jan Kalina
>
> Wildcard "\{0\}" is replaced by username in filter-name in filtering attribute mapping.
> It is correct for search of identity roles, but wrong for search roles of role - on role-recursion. In such case it should be replaced by name of that role.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (WFCORE-1062) Deployments from the domain/data/content folder goes missing after few minutes if the Host controller is started with --backup option.
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1062?page=com.atlassian.jira.plugi... ]
RH Bugzilla Integration commented on WFCORE-1062:
-------------------------------------------------
Petr Penicka <ppenicka(a)redhat.com> changed the Status of [bug 1265170|https://bugzilla.redhat.com/show_bug.cgi?id=1265170] from VERIFIED to CLOSED
> Deployments from the domain/data/content folder goes missing after few minutes if the Host controller is started with --backup option.
> --------------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-1062
> URL: https://issues.jboss.org/browse/WFCORE-1062
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 2.0.0.CR7
> Reporter: ehsavoie Hugonnet
> Assignee: ehsavoie Hugonnet
> Priority: Blocker
> Fix For: 2.0.0.CR8
>
>
> Host controller started with --backup option deletes the deployments from the domain/data/content folder after approximately 10 mins.
> The deployment is restored or recreated if the HostController is started.
> Version-Release number of selected component (if applicable): 6.4.x
> How reproducible:
> Steps to Reproduce:
>
> 1. Setup domaincontroller
> 2. Setup hostcontroller
> 3. Start domaincontroller
> 4. Start hostcontroller with --backup option.
> 5. deploy an application using cli or admin console
> ./jboss-cli.sh --connect --controller=x.x.x.x:9999 --command='deploy /PathToApp/App.war --server-groups=main-server-group'
> 6. deployments are available under $JBOSS_HOME/domain/data/content
> 7. Wait for approximately 10 minutes
> 8. Cached deployments are deleted on hostcontroller (domain/data/content is empty). Following is the logging seen on the console :
> ++++++++++++++
> [Host Controller] 14:20:40,439 INFO [org.jboss.as.repository] (Host Controller Service Threads - 4) JBAS014903: Content /NotBackedUp/JAR-Folder/EAPs/EAP6/jboss-eap-6.4.3-Patched/domain/data/content/47/1108a27fa1b82e6a92fb56ee25bc76f2625249 is obsolete and will be removed
> [Host Controller] 14:20:40,440 INFO [org.jboss.as.repository] (Host Controller Service Threads - 4) JBAS014901: Content removed from location /NotBackedUp/JAR-Folder/EAPs/EAP6/jboss-eap-6.4.3-Patched/domain/data/content/47/1108a27fa1b82e6a92fb56ee25bc76f2625249/content
> ++++++++++++++
> 9. After restarting the Host Controller, the deployment is restored and the cached deployment can now be seen under the Host Controller's domain/data/content folder.
> Actual results: Deployment folder form domain/data/content folder gets deleted after approx 10 mins and are restored if the Host Controller is restarted
> Expected results: The cached deplpyments folder should never be removed from the HostController's domain/data/content folder.
> Additional info: This does not affect the availability of the application since the applications are also availbale with the assigned server's under their data/content folder.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (WFCORE-659) standalone.sh fails to start server with debug argument on solaris 10 and HP-UX hosts
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFCORE-659?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration commented on WFCORE-659:
------------------------------------------------
Petr Penicka <ppenicka(a)redhat.com> changed the Status of [bug 1064763|https://bugzilla.redhat.com/show_bug.cgi?id=1064763] from VERIFIED to CLOSED
> standalone.sh fails to start server with debug argument on solaris 10 and HP-UX hosts
> -------------------------------------------------------------------------------------
>
> Key: WFCORE-659
> URL: https://issues.jboss.org/browse/WFCORE-659
> Project: WildFly Core
> Issue Type: Bug
> Affects Versions: 1.0.0.Beta6
> Environment: HP-UX, Solaris
> Reporter: Tomas Hofman
> Assignee: Tomas Hofman
> Fix For: 1.0.0.CR1
>
>
> Copy of https://bugzilla.redhat.com/show_bug.cgi?id=1064763
> Description of problem:
> I am unable to start standalone server with --debug [PORT] argument on Solaris 10 hosts.
> SunOS 5.10 Generic_142910-17 i86pc i386 i86pc
> [user@host bin]$ ./standalone.sh --debug
> ./standalone.sh: cannot shift
> [user@host bin]$ ./standalone.sh --debug 8787
> ./standalone.sh: bad substitution
> SunOS 5.10 Generic_118833-36 sun4v sparc SUNW,Sun-Fire-T1000
> [user@host bin]$ ./standalone.sh --debug
> ./standalone.sh: cannot shift
> [user@host bin]$ ./standalone.sh --debug 8787
> ./standalone.sh: bad substitution
> Version-Release number of selected component (if applicable):
> EAP 6.3.0.DR0
> How reproducible:
> Always
> Steps to Reproduce:
> 1. Navigate to $JBOSS_HOME/bin and run: ./standalone.sh --debug [PORT]
> Actual results:
> Server fails to start
> Expected results:
> Server will start with debugger attached to $PORT (8787 if no $PORT)
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (ELY-857) Elytron ldap-realm is not able to use LDAP attribute as principal
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/ELY-857?page=com.atlassian.jira.plugin.sy... ]
Jan Kalina closed ELY-857.
--------------------------
Resolution: Rejected
> Elytron ldap-realm is not able to use LDAP attribute as principal
> -----------------------------------------------------------------
>
> Key: ELY-857
> URL: https://issues.jboss.org/browse/ELY-857
> Project: WildFly Elytron
> Issue Type: Bug
> Components: Realms
> Affects Versions: 1.1.0.Beta16
> Reporter: Ondrej Lukas
> Assignee: Jan Kalina
> Priority: Blocker
>
> In Elytron ldap-realm is currently not possible to obtain username from LDAP attribute which is different than rdn-identifier. It means that username of identity is always the same as value of rdn-identifier attribute.
> It can cause issues when ldap-realm is used for authentication and another realm is used for authorization since data for realm authorization can depend on assigned name during authentication.
> Example:
> It seems that ldap-realm cannot be configured for following scenario: User with credentials {{someUser}}/{{Password}} is authenticated and name {{AuthenticatedUser}} is assigned to them (e.g. when calling {{./jboss-cli.sh -c -u=someUser -p=Password ':whoami'}}, then {{AuthenticatedUser}} should be printed). Following ldif is used:
> {code}
> dn: ou=People,dc=jboss,dc=org
> objectclass: top
> objectclass: organizationalUnit
> ou: People
> dn: uid=someUser,ou=People,dc=jboss,dc=org
> objectclass: top
> objectclass: person
> objectclass: inetOrgPerson
> uid: someUser
> cn: some User
> sn: AuthenticatedUser
> userPassword: Password
> {code}
> Mentioned ldif works correctly with legacy security solution.
> This missing feature can cause that migration from legacy security solution will not be possible -> we request blocker.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (WFLY-7895) NPE thrown in jboss-cli while defining already defined StringListType attribute
by Jan Tymel (JIRA)
[ https://issues.jboss.org/browse/WFLY-7895?page=com.atlassian.jira.plugin.... ]
Jan Tymel updated WFLY-7895:
----------------------------
Component/s: Security
> NPE thrown in jboss-cli while defining already defined StringListType attribute
> -------------------------------------------------------------------------------
>
> Key: WFLY-7895
> URL: https://issues.jboss.org/browse/WFLY-7895
> Project: WildFly
> Issue Type: Bug
> Components: CLI, Security
> Reporter: Jan Tymel
> Assignee: Jason Greene
>
> NullPointerException is thrown when user tries to define already (i.e. previously in current command) defined StringListType attribute. This attempt results in following stack trace and termination of jboss-cli.
> {code}
> /subsystem=elytron/provider-loader=providerLoader:add(providers=[{class-names=[com.example.Class]},class-names=[{com.example.AnotherClass}Exception in thread "Aesh Process Loop 749282235" java.lang.NullPointerException
> at org.jboss.as.cli.impl.DeploymentItemCompleter.getCandidates(DeploymentItemCompleter.java:80)
> at org.jboss.as.cli.impl.DeploymentItemCompleter.complete(DeploymentItemCompleter.java:53)
> at org.jboss.as.cli.impl.ValueTypeCompleter$ValueTypeCallbackHandler.getCandidatesFromMetadata(ValueTypeCompleter.java:433)
> at org.jboss.as.cli.impl.ValueTypeCompleter$ValueTypeCallbackHandler.getSimpleValues(ValueTypeCompleter.java:690)
> at org.jboss.as.cli.impl.ValueTypeCompleter$ValueTypeCallbackHandler.getCandidates(ValueTypeCompleter.java:573)
> at org.jboss.as.cli.impl.ValueTypeCompleter.complete(ValueTypeCompleter.java:346)
> at org.jboss.as.cli.operation.OperationRequestCompleter.complete(OperationRequestCompleter.java:276)
> at org.jboss.as.cli.operation.OperationRequestCompleter.complete(OperationRequestCompleter.java:89)
> at org.jboss.as.cli.CommandCompleter.doComplete(CommandCompleter.java:137)
> at org.jboss.as.cli.CommandCompleter.complete(CommandCompleter.java:64)
> at org.jboss.as.cli.impl.Console$Factory$1$1.complete(Console.java:143)
> at org.jboss.aesh.console.AeshCompletionHandler.complete(AeshCompletionHandler.java:155)
> at org.jboss.aesh.console.AeshInputProcessor.complete(AeshInputProcessor.java:429)
> at org.jboss.aesh.console.AeshInputProcessor.parseOperation(AeshInputProcessor.java:166)
> at org.jboss.aesh.console.Console.processInternalOperation(Console.java:775)
> at org.jboss.aesh.console.Console.execute(Console.java:735)
> at org.jboss.aesh.console.Console.access$900(Console.java:73)
> at org.jboss.aesh.console.Console$6.run(Console.java:644)
> 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:745)
> {code}
> Expected result:
> No NPE thrown, jboss-cli is not terminated.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (WFLY-7895) NPE thrown in jboss-cli while defining already defined StringListType attribute
by Jan Tymel (JIRA)
Jan Tymel created WFLY-7895:
-------------------------------
Summary: NPE thrown in jboss-cli while defining already defined StringListType attribute
Key: WFLY-7895
URL: https://issues.jboss.org/browse/WFLY-7895
Project: WildFly
Issue Type: Bug
Components: CLI
Reporter: Jan Tymel
Assignee: Jason Greene
NullPointerException is thrown when user tries to define already (i.e. previously in current command) defined StringListType attribute. This attempt results in following stack trace and termination of jboss-cli.
{code}
/subsystem=elytron/provider-loader=providerLoader:add(providers=[{class-names=[com.example.Class]},class-names=[{com.example.AnotherClass}Exception in thread "Aesh Process Loop 749282235" java.lang.NullPointerException
at org.jboss.as.cli.impl.DeploymentItemCompleter.getCandidates(DeploymentItemCompleter.java:80)
at org.jboss.as.cli.impl.DeploymentItemCompleter.complete(DeploymentItemCompleter.java:53)
at org.jboss.as.cli.impl.ValueTypeCompleter$ValueTypeCallbackHandler.getCandidatesFromMetadata(ValueTypeCompleter.java:433)
at org.jboss.as.cli.impl.ValueTypeCompleter$ValueTypeCallbackHandler.getSimpleValues(ValueTypeCompleter.java:690)
at org.jboss.as.cli.impl.ValueTypeCompleter$ValueTypeCallbackHandler.getCandidates(ValueTypeCompleter.java:573)
at org.jboss.as.cli.impl.ValueTypeCompleter.complete(ValueTypeCompleter.java:346)
at org.jboss.as.cli.operation.OperationRequestCompleter.complete(OperationRequestCompleter.java:276)
at org.jboss.as.cli.operation.OperationRequestCompleter.complete(OperationRequestCompleter.java:89)
at org.jboss.as.cli.CommandCompleter.doComplete(CommandCompleter.java:137)
at org.jboss.as.cli.CommandCompleter.complete(CommandCompleter.java:64)
at org.jboss.as.cli.impl.Console$Factory$1$1.complete(Console.java:143)
at org.jboss.aesh.console.AeshCompletionHandler.complete(AeshCompletionHandler.java:155)
at org.jboss.aesh.console.AeshInputProcessor.complete(AeshInputProcessor.java:429)
at org.jboss.aesh.console.AeshInputProcessor.parseOperation(AeshInputProcessor.java:166)
at org.jboss.aesh.console.Console.processInternalOperation(Console.java:775)
at org.jboss.aesh.console.Console.execute(Console.java:735)
at org.jboss.aesh.console.Console.access$900(Console.java:73)
at org.jboss.aesh.console.Console$6.run(Console.java:644)
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:745)
{code}
Expected result:
No NPE thrown, jboss-cli is not terminated.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (ELY-880) Unable to set IPv6 address in Elytron authentication context match-host rule
by Ilia Vassilev (JIRA)
[ https://issues.jboss.org/browse/ELY-880?page=com.atlassian.jira.plugin.sy... ]
Ilia Vassilev moved WFLY-7890 to ELY-880:
-----------------------------------------
Project: WildFly Elytron (was: WildFly)
Key: ELY-880 (was: WFLY-7890)
Component/s: Authentication Client
(was: Security)
Affects Version/s: 1.1.0.Beta18
(was: 11.0.0.Alpha1)
> Unable to set IPv6 address in Elytron authentication context match-host rule
> ----------------------------------------------------------------------------
>
> Key: ELY-880
> URL: https://issues.jboss.org/browse/ELY-880
> Project: WildFly Elytron
> Issue Type: Bug
> Components: Authentication Client
> Affects Versions: 1.1.0.Beta18
> Reporter: Martin Choma
> Assignee: Ilia Vassilev
>
> Setting IPv6 address in wildfly-config.xml cause validation error.
> {code:xml|title=wildfly-config.xml}
> <?xml version="1.0" encoding="UTF-8"?>
> <authentication-client xmlns="urn:elytron:1.0">
> <authentication-configurations>
> <configuration name="set-host-to-localhost">
> <set-host name="localhost"/>
> </configuration>
> </authentication-configurations>
> <authentication-rules>
> <rule use-configuration="set-host-to-localhost">
> <match-host name="::1"/>
> </rule>
> </authentication-rules>
> </authentication-client>
> {code}
> {code:title=server.log}
> java.lang.IllegalArgumentException: ELY01029: Invalid host specification "::1"
> at org.wildfly.security.auth.client.MatchHostRule.<init>(MatchHostRule.java:39)
> at org.wildfly.security.auth.client.MatchRule.matchHost(MatchRule.java:411)
> at org.wildfly.security.auth.client.ElytronXmlParser.parseAbstractMatchRuleType(ElytronXmlParser.java:701)
> at org.wildfly.security.auth.client.ElytronXmlParser.parseAuthenticationRuleType(ElytronXmlParser.java:467)
> at org.wildfly.security.auth.client.ElytronXmlParser.parseRulesType(ElytronXmlParser.java:484)
> at org.wildfly.security.auth.client.ElytronXmlParser.parseAuthenticationClientType(ElytronXmlParser.java:241)
> at org.wildfly.security.auth.client.ElytronXmlParser.parseAuthenticationClientConfiguration(ElytronXmlParser.java:169)
> at org.wildfly.security.auth.client.XmlConfigurationTest.testMatcHostRuleConfiguration(XmlConfigurationTest.java:175)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
> at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
> at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
> at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
> at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:367)
> at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:274)
> at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238)
> at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:161)
> at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:290)
> at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:242)
> at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:121)
> {code}
> It is because of elytron validation [1]. However don't know if just allowing ":" in regexp is valid solution.
> [1] https://github.com/wildfly-security/wildfly-elytron/blob/7debbcabc7c20be5...
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (SECURITY-882) Fix for SECURITY-868 breaks flush-cache capability
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/SECURITY-882?page=com.atlassian.jira.plug... ]
RH Bugzilla Integration commented on SECURITY-882:
--------------------------------------------------
Petr Penicka <ppenicka(a)redhat.com> changed the Status of [bug 1219778|https://bugzilla.redhat.com/show_bug.cgi?id=1219778] from VERIFIED to CLOSED
> Fix for SECURITY-868 breaks flush-cache capability
> --------------------------------------------------
>
> Key: SECURITY-882
> URL: https://issues.jboss.org/browse/SECURITY-882
> Project: PicketBox
> Issue Type: Bug
> Components: AS-Integration
> Affects Versions: PicketBox_4_0_19.Final
> Environment: EAP 6.3.3, JDV 6.1.0
> Reporter: Hisanobu Okuda
> Assignee: Stefan Guilhen
>
> The member field ThreadLocal<CompoundInfo> validatedDomainInfo was introduced for the fix of SECURITY-868. When you are authenticated, a valid security info is stored in the field thread-locally. Then, you flushes the JAAS cache via CLI or API in another thread, org.jboss.security.authentication.JBossCachedAuthenticationManager.flushCache() is invoked, but validatedDomainInfo is not flushed properly, since it is ThreadLocal. As a result, a cached security info is re-used unexpectedly.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months