SAML2 Support Listed In Metadata
Craig Pluchinsky
craigp at iup.edu
Fri May 20 07:49:52 EDT 2016
As far as disabling artifact resolution should you also remove the
corresponding bits from the default relyingparty config?
-------------------------------
Craig Pluchinsky
IT Services
Indiana University of Pennsylvania
724-357-3327
On Thu, 19 May 2016, Cantor, Scott 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
More information about the users
mailing list