authentication flow howto/tutorial

[Cantor, Scott]

> If you absolutely have to, then the solution is *not* to support that method,
> it's to configure the comparison logic in authn-comparison.xml so that it
> evaluates the methods you do support as "less than or equal to" that one.

This is untested, but the gist of the answer should be close to this:

<bean id="shibboleth.MaximumClassRefMatchFactory" parent="shibboleth.InexactMatchFactory">
        <property name="matchingRules">
            <map>
                <entry key="urn:oasis:names:tc:SAML:2.0:ac:classes:TLSClient">
                    <list>
                        <value>urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport</value>
                    </list>
                </entry>
            </map>
        </property>
</bean>

The list there should contain the values your login method actually supports.

That tells the IdP that your existing method can satisfy the broken app's request for a "maximum" of client TLS, but it allows it to continue returning what it really did.

-- Scott