OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

saml-dev message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [saml-dev] Metadata, IdP Disco, AuthnRequest, etc...


Hello --

On 11 May 2007, at 16:49, Scott Cantor wrote:

>> We would really like to have the samlp:AuthnRequest include
>> saml:Attribute queries as well.  I've seen this mentioned on the list
>> in a positive light by TC members, so I'm sure it's not anathema to
>> everyone.  Has there been any work on defining this (extremely
>> trivial) extension?  If not, I could certainly put together a  
>> document.
>
> No work done.

I'll put something together; I found the templates buried on the  
OASIS website.  Y'all prefer OOo, yes?

Incidentally, how is the Shib 2 world doing this?  I noticed on the  
wiki that it was planned for Shib 2 to shift from the AA model to a  
push -- is it doing something else, or did I misunderstand, or... ?

>> Has there been any discussion of in-band metadata exchange?  That is,
>> metadata about the issuer/requester included inside an assertion or
>> request?
>
> No, but that's a good idea, sort of. It solves distribution, I  
> guess, but
> not trust management. The problem with distributing metadata  
> piecemeal is
> how to rely on it. Without a third party signing it, the issues get  
> fairly
> complicated. But that's old news, it's true with the dynamic lookup  
> model
> now.
>
> Also, since metadata is used to figure out how to talk to somebody,  
> I don't
> see how this bootstraps. If it's IdP-first, sure, you can just send  
> it, but
> an SP needs to know where the SSO service is to start with. If you can
> distribute that piece of information (which is extremely security  
> critical
> for users, in light of phishing), why not the rest?

Well, the idea is that it wouldn't necessarily be ultra-useful for  
the assertion, but it would be tremendously useful for the  
AuthnRequest.  Assuming you have a trusted third-party signer (eg,  
the federation, that which theoretically signs the metadata anyway,  
and which changes extremely infrequently),  IdPs never have to know  
anything about SPs to do basic authentication.  My big issue managing  
metadata is that there are relatively few IdPs out there, but ideally  
lots and lots of SPs -- at least in the traditional model that Shib  
1.x attempts to solve.   The Liberty-style NameID mapping management  
is a different kettle of fish, and clearly metadata as part of the  
exchange is less useful in that model.

Incidentally, there (Shib 1.x) is where a lot of my scars come from  
in terms of managing metadata, particularly trying to do local stuff  
where one can't just download the metadata from the federation  
because you ARE the federation.  There are still pieces (in the Shib  
world, anyway) that would have to be managed regardless, like  
attribute release policies, but that's clearly not in the SAML scope.

>> This would be really helpful to minimize the amount of
>> metadata management both IdPs and SPs have to do.  Some sites cannot
>> necessarily rely on the out-of-band mechanisms defined in the
>> metadata specification (ie, DNS or well-known URLs) for various
>> reasons, so it'd be nice (and just as safe!) to have metadata
>> exchanged as part of the communication.
>
> All the trust issues apply equally to using URLs, but I think the
> operational issues are a little different and I don't know how we'd  
> address
> those.

IMHO it's not necessarily the most comfortable thing in the world for  
an IdP to make a back-channel communication with a third-party web  
server during the process of authentication.  Maybe it's irrational,  
but that bothers me.  I'd rather get the metadata for the requester  
signed by a third party, the authentication request, and the  
attribute query, all in one go, so that the transaction is simpler.   
Adding steps to the process is adding complexity.

>> In these circumstances, it might be
>> desirable to sign a SAML assertion or request with a SAML assertion.
>
> You can do that now, but you can't do it without using KeyInfo to  
> carry the
> signing assertion, as in WSS.
>
>> That is, the issuer of the SAML assertion (or the requester) acquires
>> a SAML assertion authenticating it in the context of the larger
>> federation, and then encodes that SAML assertion into another SAML
>> assertion (or request), thereby authenticating that assertion or
>> request.
>
> Yes, that's done with a HoK assertion inside the KeyInfo of the  
> signature on
> the outer one. There's no constraint on how you choose to broker  
> your trust
> model, once you get to the point of deciding if the signer is ok,  
> you're
> completely free to use anything you can put inside KeyInfo. If you  
> can't use
> KeyInfo, the only reason would be size, and you could use assertion
> references.

Oh, interesting.  That would clearly work for XMLSig-signed enclosing  
requests (again focusing on the IdP PoV of metadata management).  I  
hadn't really thought of putting it into the ds:KeyInfo element --  
that seems like a bit of a kludge, but so does everywhere else I'd  
considered putting it, particularly in the request (eg in  
samlp:Extensions).

>> Clearly it will be more complex than just putting the assertion or
>> metadata in another assertion or request for security reasons, but
>> the idea is that a given service provider or identity provider need
>> not necessarily know anything about the requesting or responding
>> party (prior to the transaction, that is).
>
> I think it's turtles all the way down. I don't think you can  
> fundamentally
> sidestep it. The best way, IMHO, to do the dynamic thing today is  
> to start
> with the existing exchange specs, because that's also consistent  
> with how
> the non-SAML world that is completely mistaken about what SAML  
> requires is
> doing.

What do you mean by that?  Also, why do what everyone else is doing  
if it's fundamentally broken?

> I don't personally think dynamic lookup "works" in the sense of
> accomplishing any kind of strong basis for accepting an assertion  
> (unless it
> ends up with a third party signer), but if people think it does,  
> the specs
> are there. I don't really follow the part where you said "some  
> people can't
> just post their metadata". Why not? How would that be harder than what
> you're suggesting? I'm talking solely the URL thing, not DDDS. I  
> know why
> that's hard.

I agree with your point about trust and dynamic lookup -- you need  
the third-party signer, and without it, it's sketchy at best.  I  
always had in mind that any of the metadata exchanges would require  
signed metadata for any real purpose.  Managing a small list of third- 
party signers (ie, federations) is much easier than managing a huge  
long list of all the SPs in a large federation, and that's the world  
I'd love to live in...

As far as "some people can't just post their metadata", I was being  
generous.  To be frank, "some people WON'T just post their  
metadata."  I can't necessarily force everyone to dedicate a URL  
inside their application (or near it, and having the requester  
identifier be a URL that is completely unrelated to the application  
(ie a central repository) seems to defeat the purpose).  If I can do  
anything to ease and aid adoption, I'd like to do that.

> And if I could get an assertion from that other party, why wouldn't  
> I be
> able to get my metadata signed? It boils down to signing a key, and  
> you have
> to do it somewhere, sometime...

Authenticating with an assertion places more of a role on the trusted  
third-party issuer, but I feel more comfortable with it in terms of  
exchanging the metadata, since it has time-limits and other  
saml:Conditions on validity.  Or, metadata could sprout a  
saml:Conditions-like element, and not rely on CRLs or a complex  
matrix on the IdP of "this metadata is no longer valid when signed by  
this key..."

>> Along those same lines, why can't the IdP Discovery Service
>> (optionally) return (signed) metadata about the requested IdP?
>
> Make it a POST coming back, you mean? In part, I think it boils  
> down to the
> distribution and trust issues. If I thought there were really  
> surmountable
> in the near term for my community, I'd probably have considered it.  
> The
> other part of it is that I think the DS concept is broken by design  
> and
> can't handle the UI for the use cases that would demand that kind of
> metadata exchange. Once you need that, you're likely past the point  
> that any
> single DS will work for your SP (i.e. the multi-fed problem).

Well, again, not necessarily true.  Once you start trafficking in  
signed metadata, as long as it's signed and you can verify the  
signer, it doesn't matter exactly how you get it, does it?  If you  
can fake signed metadata, well, the whole world starts to fall apart  
anyway.  Having the federation DS return it reduces the SP complexity  
by a little, and begins to solve the distribution problem from that  
end, too.  There's nothing saying the SP can't cache it and  
revalidate only occasionally, for performance reasons...

>> Finally, has there been any discussion on methods other than XMLSig
>> or the Simple Sign POST profile (essentially, anything besides public
>> key signatures) for authenticating SAML assertions?

> If you mean a different syntax, not that I know of. And they do  
> different
> things, obviously, Simple Signing is a protocol message level  
> mechanism for
> the front channel, the other operates at both levels and either flow.
> Nothing other than XML Signature has been proposed for assertions,  
> and I
> doubt anything could be done that would handle *general* signing, but
> something could work if you didn't have to allow for all the possible
> repackaging of an assertion.

Elaborate on that, if you don't mind -- I was under the impression  
that once an assertion was baked, it was baked, and while you could  
ship it around as XML, as a base-64 blob, or what have you, it wasn't  
essentially (ie, ignoring c14n) modified.

KH

-- 
Karsten Huneycutt
Systems Specialist, ITS Identity Management
kph@unc.edu





[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]