On Jun 7, 2005, at 10:53 PM, Scott Cantor wrote:
>> Just to clarify, the typical portal scenario that we see is where the
>> portal is directing users authenticated by an IdP in its own
>> organization to SPs in other organizations. In this case, I wouldn't
>> expect the portal to be authorized to sign AuthnRequests on behalf of
>> those SPs.
>
> Why not? Isn't that what's happening if you want signing? I guess I
> figured
> this was much *more* likely if the portal was in the same domain as
> the IdP.
> If not, it's much less likely that such impersonation could be
> permitted.
I'm probably just confused, but what I thought you were suggesting was
that the portal would be trusted with the signing key of the SP, which
I wouldn't expect if the portal lives in a separate organization.
So, for example, we might have:
1) company A with IdP_A and Portal_A
2) company B with SP_B
3) company C with SP_C
If Portal_A wants to direct users authenticated by IdP_A to SP_B and
SP_C it must construct AuthnRequests that look like they come from SP_B
and SP_C. In order for Portal_A to sign those requests it would need
SP_B's and SP_C's private signing key, which doesn't seem reasonable.
-Greg
> Of course I'm not saying people must do this, I'm just trying to see
> whether
> signing should be just ruled out as completely incompatible with the
> use
> case or not...which I'd say your response would imply?
>
> At least without a protocol to initiate the request process at an SP,
> which
> isn't defined now.
>
> -- Scott
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail. You may a link to this group and all your TCs in
> OASIS
> at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
