Practical purpose of SAMLnScopedString

[Klingenstein, Nate]

Eric,

They'll correct me if I'm wrong, but I believe the functional difference is that the IdP has a few special operations it can perform if it knows an attribute is scoped.  This largely dates back to the very early days of Shibboleth, when Scope was sent as a separate attribute in the actual Attribute on the wire.  That blew up many implementations, so the default was changed to ndk at calstate.edu<mailto:ndk at calstate.edu>.

You can find some relics of this here with "attribute" versus "inline".

https://wiki.shibboleth.net/confluence/display/IDP30/SAML2ScopedStringEncoder

As long as you're not doing anything in the IdP that requires operation on a scoped attribute and you're not releasing scopes as an attribute(and I haven't seen that in... a long time), then I don't think there will be any practical difference.

Ready for the beanbags,
Nate.

On Jul 20, 2016, at 12:20 PM, Eric Goodman <Eric.Goodman at ucop.edu<mailto:Eric.Goodman at ucop.edu>> wrote:

So this is, I think, a very basic (and probably not operationally important) question:

What is the practical value of having a SAML type of SAMLnScopedString?

We noticed that one of our IdPs is resolving ePPN as an unscoped attribute, and we wanted to fix that. Then we realized: “hey, why isn’t this already broken?” At least one of our IdPs that resolves ePPN as a scoped string still expresses the attribute in assertions as an xsd:string with no formal Scope element.

The delivered attribute-policy file on the Shib SP defines a ScopingRules that disallows “@” in the attribute value. The delivered attribute-map file invokes the ScopedAttributeDecoder. I can only assume that the ScopedAttributeDecoder is basically splitting all flat string values into scoped attributes prior to applying the policy. FWIW, nothing in the formal definition of ePPN appears to declare it formally as a SAML Scoped String either, it’s just defined as a string that it is composed of a value and a scope separated by an “@”.

So if the scoped attributes are generally expressed as strings with implicit rules, and even the Shib IdP puts them (in at least some cases) on the wire without a specified scope, what’s the practical purpose of defining the attribute as SAML2ScopedString vs just calling it a string?

--- Eric
--
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net<mailto:users-unsubscribe at shibboleth.net>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20160720/3af14ef8/attachment.html>