Shibboleth Developers

[Alistair Young <>]

> No. target specifies nothing you should depend on. The spec is clear 
> on this
> now. I hope to make it a dummy value in 1.3 like it should have been 
> before.
why not remove it altogether if it's not to be used?

does <Target> in arp.site.xml have any relation to the GET target? or 
is it used with providerId or NameQualifier? When deciding what 
attributes to release it can only go via providerId but you say it may 
not be set correctly, in which case it must be NameQualifier.
What would your advice be for specifying <Target> in a <Rule>?

> > According to SAML1.1 core AttributeQuery Resource is "the start of the
> > current document" but shibboleth sets it to the providerId. Is this
> > intentional or a config error?
>
> Intentional. We are a profile.
I thought a profile was the way in which the core SAML spec was used, 
rather than redefining parts of it?

Alistair


On 17 Mar 2005, at 15:42, Scott Cantor wrote:

> > Is there any way in shibboleth to link an AuthenticationStatement to a
> > providerId? providerId being a shibboleth specific attribute.
>
> The assertion Issuer is always the providerId. For compatibility with 
> 1.1,
> you'd have to back off to NameQualifier if Issuer isn't set right.
>
> > On initial GET, the target parameter specifies the resource the user
> > wants to access, e.g. http://site.com/page.htm and providerId states
> > who is asking.
>
> No. target specifies nothing you should depend on. The spec is clear 
> on this
> now. I hope to make it a dummy value in 1.3 like it should have been 
> before.
>
> > When the AA is contacted, the providerId isn't present but the
> > AttributeQuery Resource contains the providerId from the GET request.
>
> That is the Shibboleth profile, yes.
>
> > According to SAML1.1 core AttributeQuery Resource is "the start of the
> > current document" but shibboleth sets it to the providerId. Is this
> > intentional or a config error?
>
> Intentional. We are a profile.
>
> > Or do rules for constructing a providerId somehow tie in with
> > the SAML definition of Resource?
>
> No.
>
> > SAML1.1 supports Attribute scoping by requested resource while shibb
> > seems to replace that with scoping via provider.
>
> We pushed for the Resource idea but is was a bad mistake and we 
> corrected it
> by profiling it out of existence. SAML 2.0 does not support it.
>
> > I can see that a link between auth and attrs can be establised using
> > AttributeQuery Resource but only for shibboleth SPs. It wouldn't work
> > for non shibb ones.
>
> The only way to identify a pure SAML requester is by the certificate 
> used.
> There is no interoperable way to map credentials to a logical name in 
> SAML
> 1.1. This sucks, so I fixed it using a profile. It has nothing to do 
> with
> linking anything, I don't know what you're talking about there. It's 
> about
> authentication of the request.
>
> -- Scott