SAML2 Support Listed In Metadata

Craig Pluchinsky craigp at
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

On Thu, 19 May 2016, Cantor, Scott wrote:

> On 5/19/16, 2:59 PM, "users on behalf of Reynolds, Jeffrey" <users-bounces at on behalf of JReynolds at> 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

More information about the users mailing list