17 messages in org.oasis-open.lists.security-servicesRE: [security-services] AssertionCons...| From | Sent On | Attachments |
|---|---|---|
| Mishra, Prateek | Aug 25, 2004 9:44 am | |
| Conor P. Cahill | Aug 25, 2004 10:06 am | |
| Scott Cantor | Aug 25, 2004 10:16 am | |
| Scott Cantor | Aug 25, 2004 10:19 am | |
| Conor P. Cahill | Aug 25, 2004 10:31 am | |
| Scott Cantor | Aug 25, 2004 11:02 am | |
| Conor P. Cahill | Aug 25, 2004 11:20 am | |
| Scott Cantor | Aug 25, 2004 11:28 am | |
| Conor P. Cahill | Aug 25, 2004 11:42 am | |
| Scott Cantor | Aug 25, 2004 11:51 am | |
| Conor P. Cahill | Aug 25, 2004 9:13 pm | |
| Scott Cantor | Aug 25, 2004 9:24 pm | |
| Conor P. Cahill | Aug 25, 2004 9:26 pm | |
| Scott Cantor | Aug 25, 2004 9:31 pm | |
| Scott Cantor | Aug 25, 2004 9:39 pm | |
| Mishra, Prateek | Aug 30, 2004 1:24 pm | |
| Scott Cantor | Aug 30, 2004 1:28 pm |
| Subject: | RE: [security-services] AssertionConsumerServiceIndex vs. AssertionConsumerURL | |
|---|---|---|
| From: | Scott Cantor (cant...@osu.edu) | |
| Date: | Aug 25, 2004 11:28:48 am | |
| List: | org.oasis-open.lists.security-services | |
So here's how it's an issue:
I don't think so, but maybe I'm not clear on the attack yet...
So, the Principal somehow browses to BadProvider... BadProvider submits an AuthNRequest to IdP claiming he is SP and providing a consumerURL that points back to a BadProvider managed location. The IdP sends the response back to BadProvider at this location (and in this case we are doing a browser-post type operation, not artifact).
Right. And inside the signed assertion is:
<SubjectConfirmationData Recipient="URL submitted by bad provider">
In SAML 1.1, this was a Recipient in the Response, which was signed, but the basic approach is the same. Limit the location to which the token can be delivered.
In 2.0, I cast this as "limit the location to which the assertion can be presented in a profile and still satisfy the bearer confirmation".
ID-FF does not have this mechanism, and therefore this impersonation attack is dealt with in the manner you describe.
BadProvider can then act as a *browser* client of SP and submits the assertion as a response to the consumer URL of SP and now SP will let the BadProvider act as a bad guy on its site.
See above, this won't work.
So, the IdP shouldn't use a consumer URL unless there is some reason for it to trust it (either a signed request from a trusted party, or because of some trusted metadata or some other such equivalent).
I agree, but for other reasons, not to prevent impersonation via the SSO profile.
-- Scott