saml-dev message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: RE: [saml-dev] Distributed IDP model
- From: <michael.mccormick@wellsfargo.com>
- To: <conor.p.cahill@intel.com>, <saml-dev@lists.oasis-open.org>
- Date: Wed, 9 Aug 2006 14:21:16 -0500
Title: Distributed IDP model
Thanks Conor. I think you're saying step 2 should
involve the IDP sending a SAML assertion to the CIA. That makes sense
conceptually, but it implies that IDPs must acquire & maintain SAML servers
which partly negates the whole point of delegating SAML services to a
CIA.
Instead I think what's needed is a lightweight SOAP request
through which a IDP can ask a proxy to generate an assertion/artifact pair on
its behalf. The response would be a SAML artifact. This
request/response should ideally be part of the SAML standard
protocols.
With
regard to the IDP/proxy relationship, obviously there is a high degree of mutual
trust (which implies mutual authentication of the SOAP connection described
above). The CIA or proxy has "power of attorney" for all IDPs in its
circle of trust, and its assertions are honored by relying SPs just as they
would honor assertions received directly from a IDP. However I would not
be comfortable with IDPs providing private keys to the CIA. If assertions
are digitally signed, they should be signed using the CIA's own key
pair.
Of
course this begs the question of how the identity of the original IDP should be
reflected in the SAML assertion. It seems to me the standard assertion
schema may need to be extended to accommodate an additional element for this
purpose.
Michael
McCormick, CISSP
Lead Architect, Information Security
This message may
contain confidential and/or privileged information. If you are not the
addressee or authorized to receive this for the addressee, you must not use,
copy, disclose, or take any action based on this message or any information
herein. If you have received this message in error, please advise the
sender immediately by reply e-mail and delete this message. Thank you for
your cooperation.
We definately considered that the Assertion consumer URL
could be different than the IdP's authnrequest URL.
We did not document explicit protocols for (1) or (2)
below (and I think you're missing (0) (how the user gets to the IdP such that
the IdP knows which SP to send the user to). However, just because they
aren't documented doesn't mean that they can't be done -- (1) is done by *every*
SSO implementation that I know of, but done using non-SAML protocols. I
would imagine that some/many do (2) as well.
The tricky part in this comes down to what's in the
assertion. First off, you need to send the relying party, authentication
context info & probably subject confirmation info as well as conditions to
the CIA in step 2 (seems like you need to send the CIA an assertion to me - it
may be possible to hard-code some of this at the CIA, but I doubt you could do
all of it that way) AND, if you are signing assertions, you
somehow have to convey to the relying party that the assertion is being
generated in the name of the IdP.
An alternative model is that you use the CIA as an IdP
proxy where the IdPs do the initial authentication of the user and the CIA
accepts that, then the CIA authenticates the user to the necessary SPs, but
again the SPs would see this as an identity asserted by the CIA and not the
IdP.
Of course, if the CIA really is a OEM-like
part of the IdP, it may have the trust and
ability to act as the IdP (e.g. have the IdP's private keys so it can make
signed statements in the name of the IdP).
Conor
(1) IDP authenticates user
(2) CIA provides artifact to IDP
(3) IDP redirects browser to SP with artifact
(4) SP sends artifact to CIA for validation
(5) CIA provides assertion to SP
(6) SP provides online services to user
It's not clear to me how standard SAML protocols
would support step 2 above. What's needed is a SOAP request for which
the standard response is a SAML artifact.
Did OASIS (or LAP) consider this type of
distributed model? Any guidance on this would be much
appreciated.
Michael
McCormick, CISSP
Lead Architect, Information Security
Wells Fargo Bank
255 Second Avenue South
MAC N9301-01J
Minneapolis MN
55479
( 612-667-9227
(desk)
7
612-667-7037 (fax)
( 612-590-1437 (cell)
J michael.mccormick@wellsfargo.com (AIM)
2 612-621-1318 (pager)
* michael.mccormick@wellsfargo.com
“THESE OPINIONS ARE STRICTLY
MY OWN AND NOT NECESSARILY THOSE OF WELLS FARGO"
This message may
contain confidential and/or privileged information. If you are not the
addressee or authorized to receive this for the addressee, you must not use,
copy, disclose, or take any action based on this message or any information
herein. If you have received this message in error, please advise the
sender immediately by reply e-mail and delete this message. Thank you
for your cooperation.
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]