[Shib-Users] NameID and Attributes Setup
Paul Hethmon
standpoint, I¹m having my IdP do two-factor authentication. That is its
primary purpose. It is not giving out any other attribute information about
the user. So the applications I¹m protecting expect to get the login ID of
the user as the SAML NameID, as opposed to an attribute (just like Google
Apps does). So after quite a bit of experimenting and googling and reading
the wiki, what I eventually settled upon was this:
<resolver:AttributeDefinition id="principal" xsi:type="PrincipalName"
xmlns="urn:mace:shibboleth:2.0:resolver:ad">
<resolver:AttributeEncoder xsi:type="SAML2StringNameID"
xmlns="urn:mace:shibboleth:2.0:attribute:encoder"
nameFormat="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent" />
</resolver:AttributeDefinition>
That's the basic one in the default attributes-resolver.xml file with the
nameFormat changed to persistent. Then in attribute-filter.xml I added:
<AttributeFilterPolicy>
<PolicyRequirementRule xsi:type="basic:AttributeRequesterString"
value="http://red.hethmon.net/shibboleth-sp" />
<AttributeRule attributeID="principal">
<PermitValueRule xsi:type="basic:ANY" />
</AttributeRule>
</AttributeFilterPolicy>
So I let out that attribute to the SP I'm interested in.
On the Shib SP side, I get the login ID value in the HTTP_REMOTE_USER
variable and all is good.
So my question in all of this is whether this is the "right" approach. With
Shibboleth, it seems there is certainly more than one way to skin a cat. The
other doubt in my mind came from a page I found at USC detailing how to have
Shib talk to Google Apps in particular. On that page, they used the SAML 1.1
unspecified nameID format. That, however, did not work for me. I ended up
with a transient generated ID value. That page is here:
https://shibboleth.usc.edu/docs/google-apps/
Any feedback is appreciated.
Thanks,
Paul
-----
Paul Hethmon
Chief Software Architect
Clareity Security, LLC
865.824.1350 - office
865.250.3517 - mobile
www.clareitysecurity.com
-----
Give a man a fire and he's warm for the day. But set fire to him and he's
warm for the rest of his life.
-- Terry Pratchett, Discworld
Chad La Joie
One minor technical thing that I'd note. You should probably shouldn't
use persistent as the name identifier. That has some particular meaning
that a principal name would not have. You probably need to come up with
your own or use unspecified.
As to whether this is the "right" way, no one else but you and SP you're
dealing with can answer that. Various SPs require different information
in this field.
--
SWITCH
Serving Swiss Universities
--------------------------
Chad La Joie, Software Engineer, Net Services
Werdstrasse 2, P.O. Box, 8021 Zürich, Switzerland
phone +41 44 268 15 75, fax +41 44 268 15 68
chad....@switch.ch, http://www.switch.ch
Paul Hethmon
Thanks,
Paul
On 12/19/08 10:47 AM, "Chad La Joie" <chad....@switch.ch> wrote:
Hey Paul,
One minor technical thing that I'd note. You should probably shouldn't
use persistent as the name identifier. That has some particular meaning
that a principal name would not have. You probably need to come up with
your own or use unspecified.
Scott Cantor
> standpoint, I¹m having my IdP do two-factor authentication. That is its
> primary purpose. It is not giving out any other attribute information
about
> the user. So the applications I¹m protecting expect to get the login ID of
> the user as the SAML NameID, as opposed to an attribute (just like Google
> Apps does).
As Chad said, you can't use the persistent Format for that kind of
identifier. You're violating its requirements if you do that. The format you
use shouldn't matter in general, and unspecified should work fine, but the
question is still what the relying party expects to get.
> The other doubt in my mind came from a page I found at USC detailing how
to have
> Shib talk to Google Apps in particular. On that page, they used the SAML
1.1
> unspecified nameID format. That, however, did not work for me. I ended up
> with a transient generated ID value.
Then that's what you'll need to fix, using persistent is definitely not
correct. A persistent ID is the same as an eduPersonTargetedID.
-- Scott
Nate Klingenstein
Scott Cantor
> but it's not explicitly configured. It's the order of some elements
> somewhere, if I recall.
I believe it will just walk the resolved attribute set and look for a usable
attribute it can encode. Should just be a matter of reordering the
attributes.
-- Scott
Chad La Joie
attributes to go to a particular SP (regardless of what it gets encoded
in to) you need to create you filter policies to say that.
--
Scott Cantor
> attributes to go to a particular SP (regardless of what it gets encoded
> in to) you need to create you filter policies to say that.
That would work in most cases, including this one, since a transient has no other purpose, but it depends on the candidates for use as NameIDs. If they're otherwise usable/acceptable as Attributes, then there wouldn't be a way to guarantee which one actually gets used in the Subject, and that has implications for non-Shibboleth SAML code that isn't as flexible.
The SP's metadata is one approach, probably the "proper" one, but often that might not be possible (federations that don't allow for including that, for example).
I would have assumed that the attributes would be stored in the same order they get resolved in the file, and that that ordering would apply when it came time to pick a NameID. If not, which I could understand, I think it will create a problem in some isolated cases.
-- Scott
Chad La Joie
attribute definitions, one bearing the SAML attribute encoded and one
with the name identifier encoders then you could filter them separately.
Jira issue SIDP-239 relates to this as well.
--
Scott Cantor
> attribute definitions, one bearing the SAML attribute encoded and one
> with the name identifier encoders then you could filter them separately.
Yep, duh, that makes sense.
> Jira issue SIDP-239 relates to this as well.
I'll take a look.
-- Scott
Paul Hethmon
With the original setup, I had the SP metadata specify that it wanted a NameIDFormat of urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified and I also mapped the PrincipleName to that in attribute-resolver.xml. I also had attribute-filter.xml set up to release the PrincipleName to my SP. With this setup, however, Shib would send the transient id as the NameID value. I guess sending transient has a higher preference than sending unspecified. If I go one step further and remove the AttributeFilterPolicy for releaseTransientIdToAnyone from attribute-filter.xml, then Shib will send the PrincipleName as the unspecified format.
So, to me, the unexpected was sending transient over unspecified when I had a definition for unspecified and had the SP express a preference for it. Reading the SAML docs (saml-core-2.0-os), it doesn’t seem like either one has a preference by spec. But then again, nothing to say what Shib is doing isn’t the right thing. I guess implementation specific.
My next step was to go ahead and define my own NameIDFormat and set up the configs for that. With the transient id definition left in, this worked. It had a higher priority according to Shib and was passed thru to the SP. Then I added the attribute id to the ApplicationDefaults in shibboleth2.xml on the SP side to get it mapped into the HTTP_REMOTE_USER.
So I feel like I have a grasp on the situation/setup now.
As a more general question, how flexible are non-Shibboleth SP implementations when it comes to the NameIDFormat they support? Google wants “unspecified”, but what about a solution like Ping? Do they have flexibility?
Thanks,
Paul
Scott Cantor
> NameIDFormat of urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified and
I
> also mapped the PrincipleName to that in attribute-resolver.xml. I also
had
> attribute-filter.xml set up to release the PrincipleName to my SP. With
this
> setup, however, Shib would send the transient id as the NameID value.
Specifying unspecified makes about as much sense operationally as it sounds
in English, so we don't do that. Saying you support it means you support
anything. I think I'll get that into an errata, if that isn't self-evident.
So what you're doing there is asking for anything, which is why you get,
well, whatever.
> I guess sending transient has a higher preference than sending
unspecified.
There is no precedence at all.
> If I go one step further and remove the AttributeFilterPolicy for
> releaseTransientIdToAnyone from attribute-filter.xml, then Shib will send
> the PrincipleName as the unspecified format.
That is the solution here, yes.
> So, to me, the unexpected was sending transient over unspecified when I
had
> a definition for unspecified and had the SP express a preference for it.
That was your problem, you interpreted the metadata as being able to express
a preference for something that by definition can't be quantified. I will
attempt to get that fixed.
A comparable example is NameIDPolicy on the wire. You can't "ask" for
unspecified. That's the default...it implies you don't care.
Basically, what Google is doing is incorrect. You can't require somebody to
send you an unspecified format. It's self-contradictory.
> My next step was to go ahead and define my own NameIDFormat and set up the
> configs for that. With the transient id definition left in, this worked.
It
> had a higher priority according to Shib and was passed thru to the SP.
Right, because you asked for a specific format, unlike the original case.
> As a more general question, how flexible are non-Shibboleth SP
> implementations when it comes to the NameIDFormat they support? Google
wants
> "unspecified", but what about a solution like Ping? Do they have
> flexibility?
I'm sure Ping can handle it, but the question is how that flexibility is
manifest, whether you have to write code, and how much the application is
forced to care about the issue.
-- Scott
Paul Hethmon
When I read the specs, to me I looked at the Subject and said, that’s where my id needs to go. For me, I view that as the user’s login ID (which I think Google does too). Then I looked at the NameIDFormat specs and said, which one should I use? None of the SAML defined ones really fit the meaning of what I had, so I looked at it as I need to use “unspecified”. When you read the spec document, it does not say that “unspecified” means I don’t care which format I get, it says that the content of what I’m getting is unspecified. To me, that’s a crucial difference. Being honest here, I did not really see that I could define my own (then).
Now I don’t have the background of what went on in the OASIS committee that you do, so that may not be the intent, but if you read the saml-core doc, I think section 8.3, I’ll argue that it says what my interpretation is.
That said, I intend to specify my own format and use that, still pushing it into the Subject, since that’s where most implementations will look. Shibboleth is the swiss army knife of SSO, while a lot of others are just a simple penknife with two blades (the kind I use to be able to carry on a plane <sigh>).
Thanks,
Paul
On 12/19/08 5:33 PM, "Scott Cantor" <cant...@osu.edu> wrote:
Specifying unspecified makes about as much sense operationally as it sounds
in English, so we don't do that. Saying you support it means you support
anything. I think I'll get that into an errata, if that isn't self-evident.
So what you're doing there is asking for anything, which is why you get,
well, whatever.
> I guess sending transient has a higher preference than sending
unspecified.
There is no precedence at all.
> If I go one step further and remove the AttributeFilterPolicy for
> releaseTransientIdToAnyone from attribute-filter.xml, then Shib will send
> the PrincipleName as the unspecified format.
That is the solution here, yes.
> So, to me, the unexpected was sending transient over unspecified when I
had
> a definition for unspecified and had the SP express a preference for it.
That was your problem, you interpreted the metadata as being able to express
a preference for something that by definition can't be quantified. I will
attempt to get that fixed.
Peter Williams
If it helps, I’ll relate my mental model (which was hard learned). It’s unlikely to be correct in terms of SAML2 formalisms or factual truth, but works empirically:-
In SAML1, nameid fields had various formats=syntaxes. Different communities would use different naming constructs, to suit their legacy needs.
In SAML2, nameid format indicators are best thought of a federated-naming privacy-enhancing protocols (cleartext, persistent , transient). These protocol provide privacy semantics to (variously) the account mapped or account linked (i.e. now federated) identifier(s) by which a given principal is now known - to the IDP and/or SP. Who knows, someone will invent a new privacy-enhancement construct, some variant of nyms perhaps, indicated as format=supernym.
Google started out using the SAML2 format field in its SAML1 mode. Then, they stopped – because it’s was a bad idea. Now you stuff any bytes you like in the leaf element value. Their SP offered no ability to process persistent or transient formats, last time I looked.
C-
Once I reasoned the environment was actually functioning as described above, I _was_ able to decipher the direct meaning of the SAML2 specification text, re format, in its native terms. But, I needed that (probably incorrect) bootstrap to help me get there. Once you get there, you can discard the bootstrap.
From: Paul Hethmon
[mailto:paul.h...@clareitysecurity.com]
Sent: Friday, December 19, 2008 4:11 PM
To: Shibboleth Users
Tom Scavo
<paul.h...@clareitysecurity.com> wrote:
>
> When you read
> the spec document, it does not say that "unspecified" means I don't care
> which format I get, it says that the content of what I'm getting is
> unspecified. To me, that's a crucial difference.
FWIW, I totally agree with that interpretation.
Tom
Tom Scavo
>
> In SAML1, nameid fields had various formats=syntaxes. Different communities
> would use different naming constructs, to suit their legacy needs.
>
> In SAML2, nameid format indicators are best thought of a federated-naming
> privacy-enhancing protocols (cleartext, persistent , transient).
To a certain extent, you're right. The new persistent and transient
"formats" in SAML2 are not at all like the other NameID formats.
Persistent and transient have associated semantics whereas the rest do
not. I agree that's confusing, although I'm not sure what to do about
it at this point.
Tom
Scott Cantor
> > the spec document, it does not say that "unspecified" means I don't care
> > which format I get, it says that the content of what I'm getting is
> > unspecified. To me, that's a crucial difference.
>
> FWIW, I totally agree with that interpretation.
I am not arguing what the Format means, notwithstanding that using it is a
terribly bad idea. I'm explaining what expressing that format in a protocol
message or metadata means, namely it means nothing.
There's no debate, as I said, because of NameIDPolicy, which is 100% clear
on this. Quoting:
"If the Format value is omitted or set to
urn:oasis:names:tc:SAML:1.1:nameidformat:
unspecified, then the identity provider is free to return any kind of
identifier, subject to any additional constraints due to the content of this
element or the policies of the identity provider or principal."
As with just about everything in the metadata, it's a stand-in for things
that might go into a request or response, in this case a kind of reference
to NameIDPolicy.
It's purely an oversight that it doesn't explicitly mention the connection,
because that spec was written very quickly and without much regard for
detail in light of the fact that I was busy arguing half the time why
metadata was even needed.
HTH,
-- Scott
Scott Cantor
that
> you do, so that may not be the intent, but if you read the saml-core doc,
I
> think section 8.3, I'll argue that it says what my interpretation is.
Yes, it does, but read the section for NameIDPolicy, and I think you'll
grasp the difference between the contexts of use in an assertion and in a
request for a format.
-- Scott
Scott Cantor
communities
> would use different naming constructs, to suit their legacy needs.
All formats, then and now, mean what they're defined to mean, whether
syntax, semantics, or whatever else. That wasn't new to me in SAML 2, it was
merely clarified there because one spec I wrote and the other I didn't.
Since nobody could agree on any useful definitions for the older formats, we
deprecated them to some extent, or at least made some clarifications as to
syntax to improve interop with them.
> In SAML2, nameid format indicators are best thought of a federated-naming
> privacy-enhancing protocols (cleartext, persistent , transient).
Just because some of them now do this sort of thing doesn't mean that the
concept of a Format was altered to permit it. They could both have been
defined in SAML 1 (and we did, we had transient all along in Shibboleth).
There were some schema issues to deal with as well, but that's beside the
main point. The word "Format" isn't terribly accurate, but it's what we had
already, and nobody had a better one to use.
None of which has anything to do with Paul's issue I would add. His
interpretation of unspecified as a format is totally accurate. It's the
interpretation of that format in an SP's metadata that I'm correcting.
The question of whether an SP could request that format did come up, and it
was rejected, which is why the NameIDPolicy element definition is clear on
that point. The other text just needs to be corrected.
-- Scott
Peter Williams
I've almost got to the point where we can at least request n authentication contexts during sp initiated websso (which we now finally have firmly entrenched and operational).
Formats in requested name handling is probably 12 months away, if only because it demands more of the idp.
Scott Cantor
> because it demands more of the idp.
It's essentially non-existent in Shibboleth because there's too much history
of using attributes to supply identifiers. That's one reason I didn't
include any special support in the SP for populating NameIDPolicy, it just
wasn't interesting.
We subsequently profiled a non-ambiguous mapping for eduPerson identifier
attribute names into NameID Formats so that we could start doing this, but
with the installed base of SAML 1.1, there just isn't any movement that way
yet. It's all attributes, and transients to satisfy the need for a NameID.
-- Scott
Paul Hethmon
Scott,
Thanks for the information. I'll read that section.
I do appreciate the feedback and education. It just helps point out how much fun specs are to write, read, and interpret.
Thanks
Paul
Chad La Joie
created/used in the IdP also gives most of the information (though in
less spec'y terms).
https://spaces.internet2.edu/display/SHIB2/IdPNameIdentifier
--
Peter Williams
As
a more general question, how flexible are non-Shibboleth SP implementations
when it comes to the NameIDFormat they support? Google wants
“unspecified”, but what about a solution like Ping? Do they have
flexibility?
Thanks,
Paul
[Peter Williams] As an SP initiator, the app offloading its SAML endpoints to PingFederate server can indicate the format value to be used in the AuthnReq. The manual doesn’t say what the Ping Server SP would do with format URIs that are not those registered by SAML2 (it may reject the initiation attempt.) It doesn’t say what the Ping Federate SP would do on recognizing a non-standard format, in an inbound un/solicited assertion – of the kind that Shib generates. PingFederate is known to reject Shib unsolicited assertions – as PingFederate SP is stateful. That is, it enforces that the rule that a solicited response must match its request, per the rules in SAML2.
Whether any of that is right or wrong behavior, is almost irrelevant. That’s all the SP code will actually do. Apparently, the interworking behavior was appropriate to get a Liberty interoperable certificate, when tested with 3 other vendors systems. The only thing I ever got to interwork was Ping IDP talking to Shib2.0 SP, over sp-initiated websso.
RequestedFormat
(optional - SAML 2.0)
Specifies the value for the Format attribute in the
NameIDPolicy element of the AuthnRequest.
If not specified, the attribute is not included in the
AuthnRequest.
Scott Cantor
of
> the kind that Shib generates.
Shibboleth 2 doesn't generate anything non-standard unless you tell it to,
and it pretty much doesn't generate anything unsolicited at all.
> PingFederate is known to reject Shib
> unsolicited assertions - as PingFederate SP is stateful. That is, it
> enforces that the rule that a solicited response must match its request,
per
> the rules in SAML2.
An SP is required to support unsolicited responses (whatever I might think
of the utility of that). That requirement is exactly why implementing
correlation is a waste of time. If you have to handle a response at any
time, you can't enforce anything by assuming you know what the request
looked like because there may not be one.
-- Scott
Peter Williams
Being anal and minimalist, I configured the SP to only process "sp-initiated websso" SAML2 profile (since its ambiguous if idp-initiated websso in SAML2 even exists). Ping Federate exhibits behavior which rejects at processing time a response which is not in response to an outstanding request. TestShib's "response" was actually rejected; and the error indicated it failed due to the failure to cite the request to which it was "in response to".
We then discussed the general topic of in-response-to and unsolicited responses on this list (and the obligation of an SP to support unsolicited responses). I eventually figured that a conforming setup of PingFederate can be arranged (for conformance testing time, at least) - if I _also_ armed the idp-initiated profile support (to use Ping Federate mis-phrasing). This allows the PingFederate SP to hold state for its app's initiating request, wait for a proper response and properly fail to get one (after some timeout). Meantime, it receives an (unsolicited) response from an IDP, which it NOW processes as if no stateful request ever existed. I do not recall if TestShib was the IDP; I do recall manually confirming the absence of an in-response-to field (which satisfied the definition of an unsolicited response).
Now, that's how it appears to a mere user, anyway.
-------
I've searched my addled brain and am pretty sure I did trials of PingFederate SP that established : it will not initiate AuthnRequests with format URIs other than those standardized by OASIS. It doesn't even by default pass the format value processed on inbound Responses through to the backend applications. That is: format exists for name-federation processing requirement signaling only, and its consumed by the SP (arguing that this is the entity for whom the signal is intended).
> -----Original Message-----
> From: Scott Cantor [mailto:cant...@osu.edu]
> Sent: Wednesday, December 31, 2008 11:43 AM
> To: shibbole...@internet2.edu
> Subject: RE: [Shib-Users] NameID and Attributes Setup
>
Peter Williams
> I've searched my addled brain and am pretty sure I did trials of
> PingFederate SP that established : it will not initiate AuthnRequests
> with format URIs other than those standardized by OASIS. It doesn't
> even by default pass the format value processed on inbound Responses
> through to the backend applications. That is: format exists for name-
> federation processing requirement signaling only, and its consumed by
> the SP (arguing that this is the entity for whom the signal is
> intended).
[Peter Williams] One thing I did try out was induced PingFederate SP to request a format of encrypted (asking the IDP to encrypt the name-identifier). If a response comes back (a) without xmlenc encryption of the nameid, or (b) the SP cannot decrypt the nameid and produce a valid type (e.g. another assertion), would one not expect the SP to raise an error?
Scott Cantor
> support for SAML2 idp-initated websso profile, to use their mis-phrasing).
Yes, that's what it's normally called. I thought you were saying that it
couldn't.
> Ping Federate exhibits behavior which rejects at processing
> time a response which is not in response to an outstanding request.
> TestShib's "response" was actually rejected; and the error indicated it
> failed due to the failure to cite the request to which it was "in response
> to".
That makes sense, whether I agree with bothering to do that or not. The fact
that they can turn off the option to accept unsolicited is what I didn't
understand. That at least buys the application the freedom to actually trust
that its request happened and in a particular way. I didn't think of that
option.
> I've searched my addled brain and am pretty sure I did trials of
> PingFederate SP that established : it will not initiate AuthnRequests
with
> format URIs other than those standardized by OASIS. It doesn't even by
> default pass the format value processed on inbound Responses through to
the
> backend applications. That is: format exists for name-federation
processing
> requirement signaling only, and its consumed by the SP (arguing that this
is
> the entity for whom the signal is intended).
I find that weird and suboptimal, but not surprising (which is why I don't
suggest people rely on a NameID for communicating information they want
applications to see).
-- Scott
Scott Cantor
> request a format of encrypted (asking the IDP to encrypt the name-
> identifier). If a response comes back (a) without xmlenc encryption of the
> nameid, or (b) the SP cannot decrypt the nameid and produce a valid type
> (e.g. another assertion), would one not expect the SP to raise an error?
I would expect that, but it's not mandatory. The IdP is obligated to encrypt
something or return an error (so (a) is illegal on its part), but the SP
isn't obligated to fail if it doesn't get what it asked for. That's true of
essentially the entire message content and/or flags or indicators in
metadata. They are intended to warn the IdP that it shouldn't expect an SP
to work if it doesn't get what it wants, but it doesn't guarantee failure.
A failure to decrypt, OTOH, is a different matter, since that would
basically prevent subsequent messages like a logout from working, since the
NameID won't match. There's certainly no requirement that the EncryptedID in
a logout use the same symmetric key, so the later EncryptedID isn't going to
match.
-- Scott