Uploaded image for project: 'JBoss Enterprise Application Platform'
  1. JBoss Enterprise Application Platform
  2. JBEAP-11301

Even when using both outflow-security-domains and trusted-security-domains configuration, Elytron still forces identity to exist in a realm of target security domain

    XMLWordPrintable

Details

    • Bug
    • Resolution: Won't Do
    • Critical
    • None
    • 7.1.0.DR19
    • Security

    Description

      Using identity from other security domain should be possible without need to exists in the target domain in Elytron.

      Currently the identity from a source security domain(s) must exist in the target domain even if the identity outflow and domain trusts are configured in Elytron.

      For instance when the /core-service=management/access=identity defines the target domain and other domains (the source ones) are used in /core-service=management/management-interface=* configuration. Then IMO it's not valid to force the target to contain all the identities from sources.

      Such a configuration with "ManagementDomain" as the target domain and "KerberosDomain" as the source (e.g. mapped in a sasl-authentication-factory to native management interface):

      <management>
          <identity security-domain="ManagementDomain"/>
      ...
      <security-domain name="ManagementDomain" default-realm="ManagementRealm" permission-mapper="default-permission-mapper" trusted-security-domains="KerberosDomain" security-event-listener="local-audit">
          <realm name="ManagementRealm" role-decoder="groups-to-roles"/>
          <realm name="local" role-mapper="super-user-mapper"/>
      </security-domain>
      <security-domain name="KerberosDomain" default-realm="LdapRealm" permission-mapper="default-permission-mapper" outflow-security-domains="ManagementDomain">
          <realm name="LdapRealm"/>
      </security-domain>
      

      Forcing identities to exist in the target realm just complicates Elytron configuration.

      Attachments

        Activity

          People

            Unassigned Unassigned
            josef.cacek@gmail.com Josef Cacek (Inactive)
            Martin Svehla Martin Svehla
            Martin Svehla Martin Svehla
            Votes:
            0 Vote for this issue
            Watchers:
            5 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: