[JBoss JIRA] (WFCORE-2009) Management SSL Configuration always requires Security Realm
by Zach Rhoads (JIRA)
Zach Rhoads created WFCORE-2009:
-----------------------------------
Summary: Management SSL Configuration always requires Security Realm
Key: WFCORE-2009
URL: https://issues.jboss.org/browse/WFCORE-2009
Project: WildFly Core
Issue Type: Bug
Reporter: Zach Rhoads
Assignee: Darran Lofthouse
When configuring SSL/TLS for the management interfaces, you need to specify an (ssl-context or security-realm) and secure-socket-binding. When using ssl-context and secure-socket-binding, it fails with:
{code}
"WFLYCTL0380: Attribute 'security-realm' needs to be set or passed before attribute 'secure-socket-binding' can be correctly set"
{code}
failing operations:
{code:java}
batch
/subsystem=elytron/key-store=httpsKS:add(path=keystore.jks,relative-to=jboss.server.config.dir,credential-reference={clear-text=secret},type=JKS)
/subsystem=elytron/key-managers=httpsKM:add(key-store=httpsKS,algorithm="SunX509",credential-reference={clear-text=secret})
/subsystem=elytron/server-ssl-context=httpsSSC:add(key-managers=httpsKM,protocols=["TLSv1.1"])
/core-service=management/management-interface=http-interface:write-attribute(name=ssl-context, value=httpsSSC)
/core-service=management/management-interface=http-interface:write-attribute(name=secure-socket-binding, value=management-https)
run-batch
reload
{code}
Oddly, this will pass (specifying BOTH ssl-context and security-realm):
{code:java}
batch
/subsystem=elytron/key-store=httpsKS:add(path=keystore.jks,relative-to=jboss.server.config.dir,credential-reference={clear-text=secret},type=JKS)
/subsystem=elytron/key-managers=httpsKM:add(key-store=httpsKS,algorithm="SunX509",credential-reference={clear-text=secret})
/subsystem=elytron/server-ssl-context=httpsSSC:add(key-managers=httpsKM,protocols=["TLSv1.1"])
/core-service=management/management-interface=http-interface:write-attribute(name=ssl-context, value=httpsSSC)
/core-service=management/management-interface=http-interface:write-attribute(name=security-realm, value=ManagementDomain)
/core-service=management/management-interface=http-interface:write-attribute(name=secure-socket-binding, value=management-https)
run-batch
reload
{code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 7 months
[JBoss JIRA] (ELY-769) Extract CredentialSource interface
by David Lloyd (JIRA)
David Lloyd created ELY-769:
-------------------------------
Summary: Extract CredentialSource interface
Key: ELY-769
URL: https://issues.jboss.org/browse/ELY-769
Project: WildFly Elytron
Issue Type: Enhancement
Components: API / SPI
Reporter: David Lloyd
Assignee: David Lloyd
Fix For: 1.1.0.Beta15
Extract a base interface that supports acquiring credentials.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 7 months
[JBoss JIRA] (ELY-756) Elytron ldap-realm does not support recursive role search
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/ELY-756?page=com.atlassian.jira.plugin.sy... ]
Jan Kalina commented on ELY-756:
--------------------------------
Should be sufficient to just add attribute "recursive-depth" to the filtered attribute. It would look like:
{code:xml}
<attribute recursive-depth="1" as-rdn="cn" filter="(&(objectClass=groupOfNames)(member={0}))" filter-base-dn="ou=Roles,dc=jboss,dc=org" to="roles"/>
{code}
* Default value of "recursive-depth" woud be 0 = no recursion, only direct groups
* Value 1 for R1,R2 as above.
Recursive group will be searched using the same filter-base-dn+filter, only into wildcard will be passed DN of the group instead of user
* Or do you think standalone filter+base-dn for search of group of group can be useful? (different "member" attribute for users and for another groups?)
> 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: Jan Kalina
> 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, 7 months
[JBoss JIRA] (ELY-767) asRdn meaning in LDAP realm
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/ELY-767?page=com.atlassian.jira.plugin.sy... ]
Jan Kalina updated ELY-767:
---------------------------
Description:
Meaning of asRdn in AttributeMaping of LdapSecurityRealm is illogicaly different for filtered and simple attributes:
Currently:
* meaning of asRdn is different for mappings without filter (obtaining attribute from identity entry) and with filter (different entry)
** simple: value of attribute (defined by ldapName) is parsed as DN
** filtered: DN of the filtered entry is parsed (and ldapName is ignored - even through it is defined)
I suggest:
* when asRdn is defined:
** if ldapName will be defined, LDAP attribute will be parsed (for filtered mappings too)
** if ldapName will not be defined, DN of entry will be parsed (DN of identity entry for simple mapping)
was:
Meaning of asRdn in AttributeMaping of LdapSecurityRealm is illogicaly different for filtered and simple attributes:
Currently:
* meaning of asRdn is different for mappings without filter (obtaining attribute from identity entry) and with filter (different entry)
* simple: attribute value is parsed as DN
* filtered: DN of the whole entry is parsed (and ldapName, which is required, is ignored)
I suggest:
* when asRdn is defined:
* if ldapName will be defined, LDAP attribute will be parsed (for filtered mappings too)
* if ldapName will not be defined, DN of entry will be parsed (DN of identity entry for simple mapping)
> asRdn meaning in LDAP realm
> ---------------------------
>
> Key: ELY-767
> URL: https://issues.jboss.org/browse/ELY-767
> Project: WildFly Elytron
> Issue Type: Enhancement
> Components: Realms
> Reporter: Jan Kalina
> Assignee: Jan Kalina
>
> Meaning of asRdn in AttributeMaping of LdapSecurityRealm is illogicaly different for filtered and simple attributes:
> Currently:
> * meaning of asRdn is different for mappings without filter (obtaining attribute from identity entry) and with filter (different entry)
> ** simple: value of attribute (defined by ldapName) is parsed as DN
> ** filtered: DN of the filtered entry is parsed (and ldapName is ignored - even through it is defined)
> I suggest:
> * when asRdn is defined:
> ** if ldapName will be defined, LDAP attribute will be parsed (for filtered mappings too)
> ** if ldapName will not be defined, DN of entry will be parsed (DN of identity entry for simple mapping)
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 7 months
[JBoss JIRA] (ELY-767) asRdn meaning in LDAP realm
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/ELY-767?page=com.atlassian.jira.plugin.sy... ]
Jan Kalina commented on ELY-767:
--------------------------------
[~dlofthouse] do you agree with this change?
(this would be probably useful to do together with ELY-756 as it changes this mapping too)
> asRdn meaning in LDAP realm
> ---------------------------
>
> Key: ELY-767
> URL: https://issues.jboss.org/browse/ELY-767
> Project: WildFly Elytron
> Issue Type: Enhancement
> Components: Realms
> Reporter: Jan Kalina
> Assignee: Jan Kalina
>
> Meaning of asRdn in AttributeMaping of LdapSecurityRealm is illogicaly different for filtered and simple attributes:
> Currently:
> * meaning of asRdn is different for mappings without filter (obtaining attribute from identity entry) and with filter (different entry)
> * simple: attribute value is parsed as DN
> * filtered: DN of the whole entry is parsed (and ldapName, which is required, is ignored)
> I suggest:
> * when asRdn is defined:
> * if ldapName will be defined, LDAP attribute will be parsed (for filtered mappings too)
> * if ldapName will not be defined, DN of entry will be parsed (DN of identity entry for simple mapping)
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 7 months
[JBoss JIRA] (ELY-767) asRdn meaning in LDAP realm
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/ELY-767?page=com.atlassian.jira.plugin.sy... ]
Jan Kalina updated ELY-767:
---------------------------
Summary: asRdn meaning in LDAP realm (was: LDAP realm - AttributeMapping structure)
> asRdn meaning in LDAP realm
> ---------------------------
>
> Key: ELY-767
> URL: https://issues.jboss.org/browse/ELY-767
> Project: WildFly Elytron
> Issue Type: Enhancement
> Components: Realms
> Reporter: Jan Kalina
> Assignee: Jan Kalina
>
> Structure of AttributeMaping of LdapSecurityRealm is illogical:
> Currently:
> * meaning of asRdn is different for mappings without filter (obtaining attribute from identity entry) and with filter (different entry)
> * simple: attribute value is parsed as DN
> * filtered: DN of the whole entry is parsed (and ldapName, which is required, is ignored)
> I suggest:
> * when asRdn is defined:
> * if ldapName will be defined, LDAP attribute will be parsed (for filtered mappings too)
> * if ldapName will not be defined, DN of entry will be parsed (DN of identity entry for simple mapping)
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 7 months
[JBoss JIRA] (ELY-767) asRdn meaning in LDAP realm
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/ELY-767?page=com.atlassian.jira.plugin.sy... ]
Jan Kalina updated ELY-767:
---------------------------
Description:
Meaning of asRdn in AttributeMaping of LdapSecurityRealm is illogicaly different for filtered and simple attributes:
Currently:
* meaning of asRdn is different for mappings without filter (obtaining attribute from identity entry) and with filter (different entry)
* simple: attribute value is parsed as DN
* filtered: DN of the whole entry is parsed (and ldapName, which is required, is ignored)
I suggest:
* when asRdn is defined:
* if ldapName will be defined, LDAP attribute will be parsed (for filtered mappings too)
* if ldapName will not be defined, DN of entry will be parsed (DN of identity entry for simple mapping)
was:
Structure of AttributeMaping of LdapSecurityRealm is illogical:
Currently:
* meaning of asRdn is different for mappings without filter (obtaining attribute from identity entry) and with filter (different entry)
* simple: attribute value is parsed as DN
* filtered: DN of the whole entry is parsed (and ldapName, which is required, is ignored)
I suggest:
* when asRdn is defined:
* if ldapName will be defined, LDAP attribute will be parsed (for filtered mappings too)
* if ldapName will not be defined, DN of entry will be parsed (DN of identity entry for simple mapping)
> asRdn meaning in LDAP realm
> ---------------------------
>
> Key: ELY-767
> URL: https://issues.jboss.org/browse/ELY-767
> Project: WildFly Elytron
> Issue Type: Enhancement
> Components: Realms
> Reporter: Jan Kalina
> Assignee: Jan Kalina
>
> Meaning of asRdn in AttributeMaping of LdapSecurityRealm is illogicaly different for filtered and simple attributes:
> Currently:
> * meaning of asRdn is different for mappings without filter (obtaining attribute from identity entry) and with filter (different entry)
> * simple: attribute value is parsed as DN
> * filtered: DN of the whole entry is parsed (and ldapName, which is required, is ignored)
> I suggest:
> * when asRdn is defined:
> * if ldapName will be defined, LDAP attribute will be parsed (for filtered mappings too)
> * if ldapName will not be defined, DN of entry will be parsed (DN of identity entry for simple mapping)
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 7 months