GluuFederation / oxTrust

Gluu Server UI for managing authentication, authorization and users.
https://gluu.org/docs/ce
MIT License
134 stars 60 forks source link

Add extra attribute for email #113

Closed nynymike closed 7 years ago

nynymike commented 9 years ago

This Support Issue references an extra required attribute for the email attribute.

<resolver:AttributeEncoder xsi:type="enc:SAML2StringNameID"
nameFormat="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress" />

I wonder if we need to update the attribute form to enable the admin to specify a nameid-format ? Not sure... or perhaps we just need to add some special logic for the mail attribute.

image

ubiquitousthey commented 9 years ago

I was able to get my integration working when I changed the /opt/tomcat/conf/shibboleth2/idp/attribute-resolver.xml.vm file to look like this:

<?xml version="1.0" encoding="UTF-8"?>

<resolver:AttributeResolver xmlns:resolver="urn:mace:shibboleth:2.0:resolver"
                   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:pc="urn:mace:shibboleth:2.0:resolver:pc"
                   xmlns:ad="urn:mace:shibboleth:2.0:resolver:ad" xmlns:dc="urn:mace:shibboleth:2.0:resolver:dc"
                   xmlns:enc="urn:mace:shibboleth:2.0:attribute:encoder" xmlns:sec="urn:mace:shibboleth:2.0:security"
                   xsi:schemaLocation="urn:mace:shibboleth:2.0:resolver classpath:/schema/shibboleth-2.0-attribute-resolver.xsd
                                       urn:mace:shibboleth:2.0:resolver:pc classpath:/schema/shibboleth-2.0-attribute-resolver-pc.xsd
                                       urn:mace:shibboleth:2.0:resolver:ad classpath:/schema/shibboleth-2.0-attribute-resolver-ad.xsd
                                       urn:mace:shibboleth:2.0:resolver:dc classpath:/schema/shibboleth-2.0-attribute-resolver-dc.xsd
                                       urn:mace:shibboleth:2.0:attribute:encoder classpath:/schema/shibboleth-2.0-attribute-encoder.xsd
                                       urn:mace:shibboleth:2.0:security classpath:/schema/shibboleth-2.0-security.xsd">

    <!-- ========================================== -->
    <!--      Attribute Definitions                 -->
    <!-- ========================================== -->
#foreach( $attribute in $attrParams.attributes )
#if( ! ($attribute.name.equals('mail') || $attribute.name.equals('transientId') ) )
    <resolver:AttributeDefinition xsi:type="ad:Simple" id="$attribute.name" sourceAttributeID="$attribute.name">
        <resolver:Dependency ref="siteLDAP" />
        <resolver:AttributeEncoder xsi:type="enc:SAML1String" name="$attrParams.attributeSAML1Strings.get($attribute.name)" />
        <resolver:AttributeEncoder xsi:type="enc:SAML2String" name="$attrParams.attributeSAML2Strings.get($attribute.name)" friendlyName="$attribute.name" />
    </resolver:AttributeDefinition>
#end
#end

    <!-- Name Identifier related attributes -->
    <resolver:AttributeDefinition id="transientId" xsi:type="ad:TransientId">
        <resolver:AttributeEncoder xsi:type="enc:SAML1StringNameIdentifier" nameFormat="urn:mace:shibboleth:1.0:nameIdentifier" />
        <resolver:AttributeEncoder xsi:type="enc:SAML2StringNameID" nameFormat="urn:oasis:names:tc:SAML:2.0:nameid-format:transient" />
    </resolver:AttributeDefinition>

    <resolver:AttributeDefinition xsi:type="ad:Simple" id="mail" sourceAttributeID="mail">
        <resolver:Dependency ref="siteLDAP" />
        <resolver:AttributeEncoder
             xsi:type="enc:SAML2StringNameID"
             nameFormat="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress" />
        <resolver:AttributeEncoder xsi:type="enc:SAML1String" name="urn:mace:dir:attribute-def:mail" />
        <resolver:AttributeEncoder xsi:type="enc:SAML2String" name="urn:oid:0.9.2342.19200300.100.1.3" friendlyName="mail" />
    </resolver:AttributeDefinition>

    <!-- ========================================== -->
    <!--      Data Connectors                       -->
    <!-- ========================================== -->

    <!-- Example Static Connector -->

    <!-- LDAP Connector -->
    <resolver:DataConnector id="siteLDAP" xsi:type="dc:LDAPDirectory"
        ldapURL="$ldapUrl"
        baseDN="o=gluu"
        principal="$bindDN"
        principalCredential="$ldapPass">
        <dc:FilterTemplate>
            <![CDATA[
                (|(uid=$requestContext.principalName)(mail=$requestContext.principalName))
            ]]>
        </dc:FilterTemplate>
    </resolver:DataConnector>

    <!--resolver:DataConnector xsi:type="dc:ComputedId"
                            id="computedID"
                            generatedAttributeID="computedID"
                            sourceAttributeID="uid"
                            salt="ufujAWGSuzbCtRRcMYpnCujW0r8+55jE8Ez64AO7NV1">
        <resolver:Dependency ref="siteLDAP" />

    </resolver:DataConnector-->

    <!-- ========================================== -->
    <!--      Principal Connectors                  -->
    <!-- ========================================== -->
    <resolver:PrincipalConnector xsi:type="pc:Transient" id="shibTransient" nameIDFormat="urn:mace:shibboleth:1.0:nameIdentifier" />
    <resolver:PrincipalConnector xsi:type="pc:Transient" id="saml1Unspec" nameIDFormat="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified" />
    <resolver:PrincipalConnector xsi:type="pc:Transient" id="saml2Transient" nameIDFormat="urn:oasis:names:tc:SAML:2.0:nameid-format:transient" />
</resolver:AttributeResolver>
nynymike commented 9 years ago

ha! my crazy idea worked! But writing a custom template is not great. We should update oxTrust to render mail properly.

aliaksander-samuseu commented 9 years ago

May be then this ticket can be accounted for, also - link? It seems to be of similar type. Apparently, there is a need for using nameid of format "urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified" sometimes, as it appears that many SPs use this approach (though it's not recommended, as mentioned in shibboleth wiki). And the only way to use it atm seems to be again to modify these velocity templates directly. For example, it is possible at the moment to add a "TransientID" attribute to the list of released SAML attributes in web UI, which, if I got it correctly isn't an actual attribute, but just a way to enforce usage of "trainsientID" format for nameID. May be it's possible to implement a similar option for this "unspecified" nameid format?

aliaksander-samuseu commented 9 years ago

Another ticket of this kind: link. It seems that ability to enforce format for nameid used within a saml trust relationship via GUI controls is really in need.

nynymike commented 7 years ago

Duplicate of #274