[JBoss JIRA] (ELY-745) Using attribute name instead of OID in x500-attribute-principal-decoder
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/ELY-745?page=com.atlassian.jira.plugin.sy... ]
Jan Kalina edited comment on ELY-745 at 11/15/16 4:50 AM:
----------------------------------------------------------
[~dlofthouse]:
??I think when we talked previously an option was to create a properties file with all the OIDs as a database, they could then be classified and used in different situations.??
How do you mean "be classified" ? The OIDs should not be in collision even without categories. By which it should be categorized/classified?
Would you agree with following property file format?
{code:java}
2.5.4.4=sn,surname
2.5.4.3=cn,commonName
{code}
(first name would be primary - would by used for OID to name conversion, the others would be used for name to OID conversion only)
Should this property file replace current X500 class of constants?
was (Author: honza889):
[~dlofthouse]:
??I think when we talked previously an option was to create a properties file with all the OIDs as a database, they could then be classified and used in different situations.??
How do you mean "be classified" ? The OIDs should not be in collision even without categories.
Would you agree with following property file format?
{code:java}
2.5.4.4=sn,surname
2.5.4.3=cn,commonName
{code}
(first name would be primary - would by used for OID to name conversion, the others would be used for name to OID conversion only)
Should this property file replace current X500 class of constants?
> Using attribute name instead of OID in x500-attribute-principal-decoder
> -----------------------------------------------------------------------
>
> Key: ELY-745
> URL: https://issues.jboss.org/browse/ELY-745
> Project: WildFly Elytron
> Issue Type: Bug
> Components: X.500
> Reporter: Jan Kalina
> Assignee: Jan Kalina
> Priority: Critical
>
> Using OIDs not really convenient.
> See description of JBEAP-6100 for more details.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 8 months
[JBoss JIRA] (ELY-756) Elytron ldap-realm does not support recursive role search
by Ondrej Lukas (JIRA)
[ https://issues.jboss.org/browse/ELY-756?page=com.atlassian.jira.plugin.sy... ]
Ondrej Lukas updated ELY-756:
-----------------------------
Priority: Blocker (was: Critical)
> Elytron ldap-realm does not support recursive role search
> ---------------------------------------------------------
>
> Key: ELY-756
> URL: https://issues.jboss.org/browse/ELY-756
> Project: WildFly Elytron
> Issue Type: Bug
> Components: Realms
> Affects Versions: 1.1.0.Beta13
> Reporter: Ondrej Lukas
> Assignee: Darran Lofthouse
> Priority: Blocker
>
> Scenario:
> LDAP can include some roles which are members of other roles. I try to assigned also these "nested roles" to user during authentication/authorization process.
> In EAP 7.0 (with PicketBox) I am able to set configuration, which allows to assign these roles to user. LdapExtLoginModule with module option {{roleRecursion}} serves for this. It uses int value which determines how many levels should be searched and assigned to user. I am not able to achieve this scenario with Elytron and its ldap-realm.
> Missing this feature in Elytron can lead to situation when migration from PicketBox to Elytron will not be possible since LDAP structure for role assignment used by legacy solution will not be able to work correctly with Elytron.
> See example of LDIF for LDAP server:
> {code}
> dn: ou=People,dc=jboss,dc=org
> objectclass: top
> objectclass: organizationalUnit
> ou: People
> dn: uid=jduke,ou=People,dc=jboss,dc=org
> objectclass: top
> objectclass: person
> objectclass: inetOrgPerson
> uid: jduke
> cn: Java Duke
> sn: Duke
> userPassword: Password1
> dn: ou=Roles,dc=jboss,dc=org
> objectclass: top
> objectclass: organizationalUnit
> ou: Roles
> dn: cn=R1,ou=Roles,dc=jboss,dc=org
> objectclass: top
> objectclass: groupOfNames
> cn: R1
> member: uid=jduke,ou=People,dc=jboss,dc=org
> description: the R1 group
> dn: cn=R2,ou=Roles,dc=jboss,dc=org
> objectclass: top
> objectclass: groupOfNames
> cn: R2
> member: cn=R1,ou=Roles,dc=jboss,dc=org
> description: the R2 group
> dn: cn=R3,ou=Roles,dc=jboss,dc=org
> objectclass: top
> objectclass: groupOfNames
> cn: R3
> member: cn=R2,ou=Roles,dc=jboss,dc=org
> description: the R3 group
> {code}
> In Elytron I am able to assigned only {{R1}} role to user jduke. Legacy solution is able to use for example {{roleRecursion=1}} which results to assign roles {{R1}} and {{R2}} to user jduke.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 8 months
[JBoss JIRA] (WFLY-7588) embed-server does not start with standalone-elytron.xml
by Martin Choma (JIRA)
[ https://issues.jboss.org/browse/WFLY-7588?page=com.atlassian.jira.plugin.... ]
Martin Choma updated WFLY-7588:
-------------------------------
Priority: Blocker (was: Major)
> embed-server does not start with standalone-elytron.xml
> -------------------------------------------------------
>
> Key: WFLY-7588
> URL: https://issues.jboss.org/browse/WFLY-7588
> Project: WildFly
> Issue Type: Bug
> Components: CLI, Security
> Affects Versions: 11.0.0.Alpha1
> Reporter: Martin Choma
> Priority: Blocker
>
> I am unable to start embed-server with standalone-elytron.xml
> 1){{./jboss-cli.sh}}
> 2) {{embed-server --std-out=echo -c=standalone-elytron.xml}}
> 3) server is missing org.wildfly.security.security-domain.ManagementDomain, which is however registered in elytron subsystem.
> Starting {{./standalone.sh -c=standalone-elytron.xml}} works fine.
> Full log:
> {code}
> [mchoma@localhost bin]$ ./jboss-cli.sh
> You are disconnected at the moment. Type 'connect' to connect to the server or 'help' for the list of supported commands.
> [disconnected /] embed-server --std-out=echo -c=standalone-elytron.xml
> 08:15:40,801 INFO [org.jboss.modules] (AeshProcess: 1) JBoss Modules version 1.6.0.Beta3
> 08:15:40,845 INFO [org.jboss.msc] (AeshProcess: 1) JBoss MSC version 1.2.7.Final-redhat-1
> 08:15:40,916 INFO [org.jboss.as] (MSC service thread 1-6) WFLYSRV0049: JBoss EAP 7.1.0.Alpha1 (WildFly Core 3.0.0.Alpha12-redhat-1) starting
> 08:15:41,088 INFO [org.jboss.as.domain.management] (MSC service thread 1-5) WFLYDM0136: Registered OpenSSL provider
> 08:15:41,804 INFO [org.wildfly.security] (Controller Boot Thread) ELY00001: WildFly Elytron version 1.1.0.Beta13
> 08:15:41,805 INFO [org.wildfly.extension.elytron] (Controller Boot Thread) WFLYELY00001: Activating Elytron Subsystem Elytron Version=1.1.0.Beta13, Subsystem Version=1.0.0.Alpha13
> 08:15:41,811 INFO [org.jboss.as.controller.management-deprecated] (Controller Boot Thread) WFLYCTL0028: Attribute 'security-realm' in the resource at address '/subsystem=undertow/server=default-server/https-listener=https' is deprecated, and may be removed in future version. See the attribute description in the output of the read-resource-description operation to learn more about the deprecation.
> 08:15:41,859 INFO [org.jboss.as.patching] (MSC service thread 1-6) WFLYPAT0050: JBoss EAP cumulative patch ID is: base, one-off patches include: none
> 08:15:42,024 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([
> ("core-service" => "management"),
> ("access" => "identity")
> ]) - failure description: {
> "WFLYCTL0412: Required services that are not installed:" => ["org.wildfly.security.security-domain.ManagementDomain"],
> "WFLYCTL0180: Services with missing/unavailable dependencies" => ["org.wildfly.management.identity is missing [org.wildfly.security.security-domain.ManagementDomain]"]
> }
> 08:16:19,546 INFO [org.jboss.as] (MSC service thread 1-4) WFLYSRV0050: JBoss EAP 7.1.0.Alpha1 (WildFly Core 3.0.0.Alpha12-redhat-1) stopped in 3ms
> Cannot start embedded server: WFLYEMB0021: Cannot start embedded process: java.lang.InterruptedException
> [disconnected /]
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 8 months
[JBoss JIRA] (WFCORE-1983) CLI type decision INT/STRING LONG/STRING
by Jean-Francois Denise (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1983?page=com.atlassian.jira.plugi... ]
Jean-Francois Denise commented on WFCORE-1983:
----------------------------------------------
Yes, a STRING instead of an INT.
In the reported issue (JBEAP-6915), the write-attribute doesn't try to convert to a number but check for the right type and fails. So it seems that some operations are smart enough to adapt to the received value, others (such as write-attribute) expect the exact type.
> CLI type decision INT/STRING LONG/STRING
> ----------------------------------------
>
> Key: WFCORE-1983
> URL: https://issues.jboss.org/browse/WFCORE-1983
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI
> Reporter: Jean-Francois Denise
> Assignee: Jean-Francois Denise
>
> It happens that the CLI does a custom parsing of the value in case ModelNode.fromString fails (whatever the exception).
> The issue is that the custom parsing doesn't follow the ModelNode parsing syntax and parse everything as String. So the resulting ModelNode that is serialised and sent to the server has been transformed.
> I am surprised that we don't have more of such failures. For example, when numbers are located inside custom complex structure such as: {mynumber=9999} that will be sent as an OBJECT containing a STRING although the valid DMR syntax {"my number"=>999} would be sent as an OBJECT containing an INT.
> Some server side subsystems are smart enough to call into asXXX methods and not check the type?
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 8 months
[JBoss JIRA] (ELY-757) Don't use String toUpperCase/toLowerCase in the testsuite without Locale provided
by Josef Cacek (JIRA)
Josef Cacek created ELY-757:
-------------------------------
Summary: Don't use String toUpperCase/toLowerCase in the testsuite without Locale provided
Key: ELY-757
URL: https://issues.jboss.org/browse/ELY-757
Project: WildFly Elytron
Issue Type: Bug
Components: Testsuite
Affects Versions: 1.1.0.Beta13
Reporter: Josef Cacek
Assignee: Josef Cacek
The {{String.toUpperCase()}} and {{String.toLowerCase()}} methods depend on the system locale. We should avoid using them in the Elytron testsuite and use the overloaded method with {{Locale}} parameter instead.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 8 months
[JBoss JIRA] (WFLY-7591) Search time limit for ldap search is not configurable in Elytron ldap-realm
by Ondrej Lukas (JIRA)
[ https://issues.jboss.org/browse/WFLY-7591?page=com.atlassian.jira.plugin.... ]
Ondrej Lukas closed WFLY-7591.
------------------------------
Resolution: Duplicate Issue
Issue if duplicate of WFLY-7473.
> Search time limit for ldap search is not configurable in Elytron ldap-realm
> ---------------------------------------------------------------------------
>
> Key: WFLY-7591
> URL: https://issues.jboss.org/browse/WFLY-7591
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 11.0.0.Alpha1
> Reporter: Ondrej Lukas
> Assignee: Darran Lofthouse
> Priority: Critical
>
> Scenario:
> I try to configure Elytron ldap-realm with some timeout limit for LDAP search.
> It seems there is no option to set search time limit for Elytron ldap-realm. Implementation in Elytron seems that feature is developed, but it is not configurable from server configuration. Legacy security solution allows to configure search time limit for searching LDAP through searchTimeLimit option from LdapExtLoginModule.
> Since this feature was provided by legacy solution it should be also available in Elytron.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 8 months
[JBoss JIRA] (WFCORE-1980) Property file passed via CLI does not resolve expressions with relative path value in vault attributes
by Chao Wang (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1980?page=com.atlassian.jira.plugi... ]
Chao Wang edited comment on WFCORE-1980 at 11/15/16 3:54 AM:
-------------------------------------------------------------
{noformat}
As the example uses vault.keystore.url=${jboss.server.config.dir}/vault/vault.keystore in vault.properties.
CLIExpressionResolver tries to recursively resolve expression ${vault.keystore.url} in command
/core-service=vault:add(vault-options=[("KEYSTORE_URL" => "${vault.keystore.url}"), ... ...
When it finds ${jboss.server.config.dir}/vault/vault.keystore in which jboss.server.config.dir can NOT be found in system properties in CLI side.
But it is a legal property in server side.
Method resolveOrOriginal therefore catches UnresolvedExpressionException and returns the original value ${vault.keystore.url} for KEYSTORE_URL which causes the error.
{noformat}
was (Author: soul2zimate):
As the example uses vault.keystore.url=${jboss.server.config.dir}/vault/vault.keystore in vault.properties.
CLIExpressionResolver tries to recursively resolve expression ${vault.keystore.url} in command
/core-service=vault:add(vault-options=[("KEYSTORE_URL" => "${vault.keystore.url}"), ("KEYSTORE_PASSWORD" => "${vault.keystore.password}") ... ...
When it finds ${jboss.server.config.dir}/vault/vault.keystore in which jboss.server.config.dir can NOT be found in system properties in CLI side, but it is a legal property in server side.
Method resolveOrOriginal therefore catches UnresolvedExpressionException and returns the original value ${vault.keystore.url} for KEYSTORE_URL which causes the error.
> Property file passed via CLI does not resolve expressions with relative path value in vault attributes
> ------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-1980
> URL: https://issues.jboss.org/browse/WFCORE-1980
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI
> Affects Versions: 3.0.0.Alpha12
> Reporter: Chao Wang
> Assignee: Chao Wang
> Priority: Minor
>
> Property file passed via CLI with --properties option does not resolve expressions in EAP 7, where in EAP 6 it works fine.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 8 months