v2->v3 upgrade, google apps

[Baron Fujimoto]

On Wed, Jul 13, 2016 at 09:10:43PM +0000, Cantor, Scott wrote:
>On 7/13/16, 4:35 PM, "users on behalf of Baron Fujimoto" <users-bounces at shibboleth.net on behalf of baron at hawaii.edu> wrote:
>
>> Our upgraded legacy v2 config was generating an "Invalid Email" error from
>> Google after authenticating. Searches turned up the following representative
>> thread that suggested a solution:
>
>There's no reason for that to be true. A legacy config, reused in V3, should produce identical NameID behavior. But your problem is you're not using a legacy config, so you're redoing this from scratch.
>
>It's worth noting that Google does *not* require the "unspecified" format. If it ever did, it doesn't now. So the right thing to do is to use one that's real, and you can simply drive that with metadata if you want.
>    
>> So I added the following to relying-party.xml:
>
>That's *not* a legacy config. If you're upgrading and using the old config, it should work. If you're not, then there are things you need to do in the new config that are the same as what you had to have done in the old one. The V2 method of specifying the format to use is exactly the same, setting nameIDFormatPrecedence, or using metadata.
>
>>    and in saml-nameid.xml:
>
>Again, you certainly *can* do that. That's not upgrading, that's starting from scratch, and that is the "newer" way of doing it.
>
>> But I am now getting the following error:
>
>Your relying-party file is apparently some kind of hybrid. You can't mix native Spring XML inside the old custom format/schema with the <RelyingParty> elements.
>
>> Is this because the the upgraded legacy relying-party.xml is using v2
>> compatibility and thus the added bean config is not available?
>
>No, it's because you're mixing dialects mainly, but it happens to be true that you can't use the Spring format unless you switch it out of that legacy mode also.
>
>If you redo the r-p file into the newer Spring syntax, then it needs to be both correct XML that is not trying to mix schemas, and you have to tell it you're doing this by flipping the property in services.properties so it knows you're not using the legacy config anymore.
>
>> Does this mean the v2 compatible relying-party.xml must be upgraded to the newer v3
>> style for this to work, or is this being caused by something else?
>
>You can't use Spring syntax in a legacy file. I don't know what "this" is, but there is absolutely no requirement to redo your relying-party file to make a custom NameID work.

Well, ok, so I get that the hybrid thing is a no-go, as I suspected
may have been the cause of the aforementioned "Invalid Content" error.

However, it's also the case that reusing the original post-upgrade
metadata and relying-party.xml[*] results in the "Invalid Email" error
when testing using the /etc/hosts method. All my searches only turn up
references to using the unspecified-format configs (including the Shib20
docs). The only IdPv3 results I could find seem to employ the new style
syntax. If someone turns up more apropos results than I found, your
Google-fu is better than mine.

[*] modulo the Post-Upgrade tasks for relying-party.xml as described in
<https://wiki.shibboleth.net/confluence/display/IDP30/UpgradingFromV2#UpgradingFromV2-Post-UpgradeTasksforrelying-party.xml>

Based on your suggestions and further experimentation, I set the format
to something other than unspecified in the the attribute resolver and
Google metadata and, I have something that now seems to work with the
legacy v2 configs. For the benefit of anyone else who may be in the same
boat, this is what I wound up with:

===== attribute-resolver.xml =====
    <!-- principal -->
    <resolver:AttributeDefinition xsi:type="ad:PrincipalName"
            id="principal" >

        <!-- uid: OID 0.9.2342.19200300.100.1.1 -->
        <resolver:AttributeEncoder xsi:type="enc:SAML2StringNameID"
                nameFormat="urn:oid:0.9.2342.19200300.100.1.1" />

    </resolver:AttributeDefinition>
    <!-- /principal -->
=====

===== attribute-resolver.xml =====
    <!-- google.com -->
    <afp:AttributeFilterPolicy id="Google">
        <afp:PolicyRequirementRule xsi:type="basic:AttributeRequesterString"
                value="google.com" />

        <afp:AttributeRule attributeID="principal">
            <afp:PermitValueRule xsi:type="basic:ANY" />
        </afp:AttributeRule>

    </afp:AttributeFilterPolicy>
    <!-- /google.com -->
=====

===== google-metadata.xml =====
<EntityDescriptor entityID="google.com" xmlns="urn:oasis:names:tc:SAML:2.0:metadata">
    <SPSSODescriptor protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">
        <NameIDFormat>urn:oid:0.9.2342.19200300.100.1.1</NameIDFormat>
        <AssertionConsumerService index="1" Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
            Location="https://www.google.com/a/foo.example.edu/acs" />
    </SPSSODescriptor>
</EntityDescriptor>
=====

Maybe this is is still "wrong", but it seems to be working.

Aloha,
-baron
-- 
Baron Fujimoto <baron at hawaii.edu> :: UH Information Technology Services
minutas cantorum, minutas balorum, minutas carboratum desendus pantorum