[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 solutions: 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 address. 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. ~ESP 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