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


Help: OASIS Mailing Lists Help | MarkMail Help

security-services message

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

Subject: Re: Contradictory requirements?

>>>>> "TM" == Tim Moses <tim.moses@entrust.com> writes:

    TM> The fact that Web server n is able to verify that assertion 1
    TM> was issued by Web server 1 is no help.  Don't you agree?

So, I think the problem you're describing is this:

1) Moriarty obtains AuthC Assertion 1 from Web Server 1 by legitimate
   or illegitimate means.

2) Moriarty sends Ticket M to Web Server N.

3) Web Server N blithely asks Moriarty's SAML processor for the
   assertion associated with Ticket M.

4) The processor gladly provides AuthC Assertion 1.

5) Web Server N logs Moriarty in with the environment of Web User
   (identified in AuthC Assertion 1).

I agree that this is a problem. To me, there seem to be two possible

A) Web Server N doesn't talk SAML with untrusted partners (especially
   ones named Moriarty B-).

B) AuthC Assertion 1 contains externally verifiable information about
   Web User or Web User's operating environment -- for example, an IP

Put together, these could mitigate the attack, but there are ways to
get around each.

Another possibility, which I think you're suggesting, is that there's
an extra step where Web Server N validates the browser's operating
environment using a redirect. The query is essentially, "Is this the
environment of the user identified by AuthC Assertion 1?". Bouncing
the user back to Web Server 1 puts them back in that environment, and
Web Server 1 can use more direct means (cookies, basic auth, certs,
what have you) to check the environment. W.S. 1 can then re-direct the
user back to W.S. N with a yes or no answer.

Is that what you're suggesting? I wonder if you could maybe draw it
out and submit a draft document to the bindings group for comment.


P.S. As to trust between partners: yes, even though W.S. N may trust
W.S. N-1, it may not trust W.S. N-2, N-3, dot dot dot. It seems like
the proper way to deal with this is to have two kinds of trust: one
where W.S. N trusts W.S. N-1 to authenticate users directly and pass
on those users, and one where W.S. N trusts W.S. N-1 to handle
third-party assertions and users correctly. That is, N trusts N-1 to
give trust correctly.

Evan Prodromou, Senior Architect        eprodromou@securant.com
Securant Technologies, Inc.             415-856-9551

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

Powered by eList eXpress LLC