SAML2 Support Listed In Metadata

[Reynolds, Jeffrey]

Seems pretty sound to me, I’ll just stick with the old school data connector definitions for now.  And thanks for the recommendation about disabling artifact resolution all together.  This will make my deployment a bit easier.

Much obliged,

Jeff

On 5/19/16, 3:28 PM, "users on behalf of Cantor, Scott" <users-bounces at shibboleth.net on behalf of cantor.2 at osu.edu> wrote:

>On 5/19/16, 2:59 PM, "users on behalf of Reynolds, Jeffrey" <users-bounces at shibboleth.net on behalf of JReynolds at utdallas.edu> wrote:
>
>>Second, and I think I know the answer to this but I have to ask, if we declare that we
>> support “urn:oasis:names:tc:SAML:2.0:protocol” in our metadata file does this mean we
>> also have to support artifact resolution?
>
>No, and if you don't want to support it, I'd advise (in addition to dropping the metadata about it) setting idp.artifact.enabled to false. That will prevent it from responding to requests via that binding, avoiding cases where the SP might get sent one and then not find an endpoint to resolve it with.
>
>As far as LDAP goes, my opinion is that the use of properties for the resolution of attributes was a bad idea in general and I would just ignore it. I don't know what 3.3 will do by default but my general attitude right now is to look for properties to get rid of in a number of areas.
>
>Properties don't really allow editing the XML to be avoided and they destroy locality of reference and reloadability (you can make properties reloadable, kind of, but that's a swamp and best avoided, since not everything using them will see the change, leading to total chaos). They're useful for some things but very limiting in others.
>
>-- Scott
>
>
>-- 
>To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net