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] Front-channel AttributeQuery Profile

Scott Cantor wrote on 2009-11-11:
> Every time you move the client around and rely on bearer security, you
> open new attacks. By limiting it to one assertion up front, and then
> on a shared identifier (which can easily be an encrypted/changing
> and include requirements to present the original assertion as a HoK proof
> token), the query doesn't open up new exposures.

I guess I should add, sure, if you're talking about cold-calling a third
party AA that has no shared link to the original IdP, then you have no other
option but front-channel. In that case, I think my point is that there's not
really a problem with including a NameID if you did that, but you could
include the Bearer SubjectConfirmation by itself as well. You'd basically
say "the assertions should have exactly *this* SubjectConfirmation", meaning
it would contain the Recipient bit referencing the SP endpoint and so forth.

But I don't think a UI that bounces a user around all over the place is very
desirable anyway. It makes more sense to me to encode some kind of
information about the identity links required from the IdP as part of the
initial SSO step, and allow that to be checked or established up front,
before ever returning the user in the first place.

-- Scott

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