Jiri Kuthan <[EMAIL PROTECTED]> wrote:
> I'm personally missing scenarios which
>
> - use redirection as opposed to proxy mode. IMO, it is beneficial to have
> the AS operated in 3xx mode for better scalability.
Perhaps you could explain a bit more what you mean here because it isn't all
that clear what the differences would be. In poking around thru, say, RFC3665
section "3.6. Session via Redirect and Proxy Servers with SDP in ACK", it
isn't clear to me that there is necessarily a salient difference between it's
scenario and the one depicted in draft-ietf-sip-saml-02 fig 1.
Here's RFC3665 Session via Redirect and Proxy Servers..
Alice Redirect Server Proxy 3 Bob
| | | |
| INVITE F1 | | |
|--------------->| | |
| 302 F2 | | |
|<---------------| | |
| ACK F3 | | |
|--------------->| | |
| INVITE F4 | |
|-------------------------------->| INVITE F5 |
| 100 F6 |--------------->|
|<--------------------------------| 180 F7 |
| 180 F8 |<---------------|
|<--------------------------------| |
| | 200 F9 |
| 200 F10 |<---------------|
|<--------------------------------| |
| ACK F11 | |
|-------------------------------->| ACK F12 |
| |--------------->|
| Both Way RTP Media |
|<================================================>|
| | BYE F13 |
| BYE F14 |<---------------|
|<--------------------------------| |
| 200 F15 | |
|-------------------------------->| 200 F16 |
| |--------------->|
| | |
..and here's -sip-saml-02 fig 1..
+--------+ +--------------+ +--------+
|Alice@ | |Authentication| | Bob@ |
|example | |Service | |example2|
|.com | |@example.com | |.com |
+---+----+ +------+-------+ +---+----+
| | |
| INVITE | |
|---------------------->| |
| From:[EMAIL PROTECTED] | |
| | |
| 407 Proxy auth. req. | |
|<----------------------| |
| Challenge | |
| | |
| ACK | |
|---------------------->| |
| | |
| INVITE w/authn creds | |
|---------------------->| |
| | INVITE |
| | w/Identity header |
| |--------------------->|
| | and Identity-Info |
| | |
| | HTTP GET SAML assn |
| |<==================== |
| | and domain cert |
| | |
| | HTTP 200 OK + assn |
| |=====================>|
| | and domain cert |
| 200 OK | |
|<----------------------+----------------------|
| | |
..so it seems that given the way in which RFC4474 works, either of the Redirect
server or Proxy 3 in the former figure could instigate authn of the user/UAC,
whereupon things would proceed more-or-less as depicted in the latter.
yes/no?
> - use SAML-by-value, in addition to SAML-by-reference. I personally find
> the SAML-by-reference quite non-real-time and harder-to-scale too.
Yes, this is not-yet-well-resolved piece of the architecture. Given present
restrictions wrt SIP intermediaries only being able to add SIP headers to a SIP
request message -- it offhand would have to be the UAC that embeds a SAML
assertion into a SIP request it is originating.
We (SIP WG) should perhaps think about this and whether we think it is a
practical use case that would indeed see some use. Below is one example of such
an approach (there's various ways to approach its details). Is this an approach
we should pursue in addition to the one presently spec'd in -sip-saml-2 ?
> Perhaps there are arguments why proxy+by/reference is the best thing, but
> if that's the case I think they should be mentioned in the document.
Yes, ok. Part of the rationale was that this sort of approach will work with
present-day unmodified UACs, and all of the workable
"include-SAML-assertion-by-value" approaches that we could think of involved
UAC enhancements to support the new funtionality (this of course skirts the
controversial sip-proxy-placing-BLOB-values-in-SIP-header approach, e.g. using
a data: URL).
So we felt that specifying the draft narrowly, and focusing on enhancements to
proxy-tier functionality was the way to go for now.
thoughts? HTH,
=JeffH
-------
Fig 4: "caller-driven, authn+attr, SAML Assertion embedded in INVITE"
Caller explicitly executes <samlp:AuthnRequest> protocol, i.e.
"caller-driven" in that caller stipulates at least some of info
that is to be embodied in resulting assertion.
Caller places SAML Assertion in INVITE msg body; Assertion has an
<saml:AuthnStatement> and optionally a <saml:AttributeStatement>.
Callee obtains SAML Assertion directly from INVITE message.
protocol message count (only include msgs w/CSeq=N+1):
Caller-to-AS: 3
AS-to-callee: 1
Protocols employed: SIP and SAML (via HTTP/SOAP)
NOTE: The interaction between caller and the AS is
in the style of the "SAML Token Service", which is
specified in draft form in section
"3.3 SAML Token Service Profile" of [9].
Caller and AS must speak at least one flavor of SAML protocol.
Relying party needs only to be capable of understanding
SAML assertion. Does not need to employ any SAML protocols.
[9] SAML 2.0 Single Sign-On with Constrained Delegation
(and SAML Token Service Proposal (Shib design note))
http://shibboleth.internet2.edu/docs/draft-cantor-saml-sso-delegation-01.pdf
Callee's UA or
Caller's Domain's Callee's Domain's
Caller AS & SIP Proxy SIP Proxy
+--------+ +--------------+ +--------+
|Alice@ | |Authentication| | Bob@ |
|example | |Service | |example2|
|.com | |@example.com | |com |
| | | (AS) | | |
+---+----+ +------+-------+ +---+----+
- - | | |
^ ^ | INVITE | |
| | |---------------------->| |
| | From:[EMAIL PROTECTED] | |
| C | To:sip:[EMAIL PROTECTED]| |
| S | | |
| e | 407 Proxy auth. req. | |
| q |<----------------------| |
| | Challenge | |
| = | | |
| | | |
| N | | |
| | | |
| | | ACK | |
| V |---------------------->| |
| - | | |
| | | |
| | [Alice marshalls | |
| | authn credentials | |
| | in resp to challenge]| |
| | | |
| | | |
| - |Request Authn+Attr Assn| |
| ^ |via Authn Request Prot | |
| . |======================>| |
| . | <samlp:AuthnRequest> | |
| . | <samlpext:RespondTo> | |
| . | [EMAIL PROTECTED] | [AS is configured |
| . | | OOB to "know" which |
| . | Assn returned | "profile attributes"|
| . |<======================| to return in Assns. |
| . | <samlp:Response> | Relying party meta- |
| . | <saml:Assertion> | data could be also |
| . | <saml:Subject> | employed. Or SAML |
| . | <saml:NameID> | request protocol |
| . | [EMAIL PROTECTED]| extension could be |
| . | <saml:AuthnStatement> used.] |
| . | <saml:AttrStatement>| |
| . | foo=bar | |
| . | | |
. | | |
D . | | |
. | INVITE + authorization| |
I | | header w/marshalled creds |
| |---------------------->| |
A | | From:[EMAIL PROTECTED] | |
| | To:sip:[EMAIL PROTECTED]| |
L | | <saml:Assertion> | |
| | <saml:Subject> | |
O | | <saml:NameID> | |
| | [EMAIL PROTECTED]| |
G | | <saml:AuthnStatement> |
| | <saml:AttrStatement>| |
| | | foo=bar | |
| | | | |
| | | | |
| | | | |
| | |INVITE + authorization|
| C | |header w/marshalled creds
| S | |--------------------->|
| e | | From:[EMAIL PROTECTED] | [this would
| q | | To:sip:[EMAIL PROTECTED] thus convey an
| | | <saml:Assertion> | "unsolicited
| = | | <saml:Subject> | response" as
| | <saml:NameID> | discussed in
| | [EMAIL PROTECTED] [5] & [3]. ]
| | <saml:AuthnStatement>
| | | <saml:AttrStatement>
| N | | foo=bar |
| | | |
| + | | |
| | | |
| 1 | | |
| | | |
| | | | |
| | | 200 OK | |
. V |<----------------------+----------------------|
. - | | |
.
.
V
-------
end
_______________________________________________
Sip mailing list https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [EMAIL PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip
