OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

saml-dev message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: RE: [saml-dev] SAML Interoperability Demo and the 5 URLs


Bhavna - 
>Since there is a need to run inter site URL and art receiver url on 
> different protocols one http the other https, I was thinking 
> along having 2 ports open one http and the other https. 
According to Prateek's spec., which follows B/A profile, the following
MUST use SSL:
1. Intersite Transfer URL: This is the place where the user sends
authentication credentials and receives the artifact.
2. Artifact Receiver: this is the place where the user sends the
artifact.

Therefore, intersite transfer URL and art reciever url must use HTTP
over SSL. We can only use HTTP for the portal URL and assertion consumer
application

---------------------------
Jahan Moreh
Chief Security Architect
tel: 310.286.3070
fax: 310.286.3076


> -----Original Message-----
> From: Bhavna Bhatnagar [mailto:bhavna.bhatnagar@sun.com] 
> Sent: Friday, May 17, 2002 8:30 AM
> To: pmishra@netegrity.com; Irving.Reid@baltimore.com
> Cc: saml-dev@lists.oasis-open.org
> Subject: RE: [saml-dev] SAML Interoperability Demo and the 5 URLs
> 
> 
> Irving,
> In our case we have the same scenario. In fact our inter site 
> URL and art receiver url are the same. SOAP Responder is 
> different and they all have their own path component. Since 
> there is a need to run inter site URL and art receiver url on 
> different protocols one http the other https, I was thinking 
> along having 2 ports open one http and the other https. Not 
> sure I understand why you cannot have different port numbers 
> in your case though...
> 
> Bhavna
> 
> >Content-return: allowed
> >Date: Thu, 16 May 2002 22:47:32 -0400
> >From: Irving Reid <Irving.Reid@baltimore.com>
> >Subject: RE: [saml-dev] SAML Interoperability Demo and the 5 URLs
> >To: "'Mishra, Prateek'" <pmishra@netegrity.com>
> >Cc: saml-dev@lists.oasis-open.org
> >MIME-version: 1.0
> >List-Owner: <mailto:saml-dev-help@lists.oasis-open.org>
> >List-Post: <mailto:saml-dev@lists.oasis-open.org>
> >List-Subscribe: <http://lists.oasis-open.org/ob/adm.pl>,
> <mailto:saml-dev-request@lists.oasis-open.org?body=subscribe>
> >List-Unsubscribe: <http://lists.oasis-open.org/ob/adm.pl>,
> <mailto:saml-dev-request@lists.oasis-open.org?body=unsubscribe>
> >List-Archive: <http://lists.oasis-open.org/archives/saml-dev/>
> >List-Help: <http://lists.oasis-open.org/elists/admin.shtml>,
> <mailto:saml-dev-request@lists.oasis-open.org?body=help>
> >List-Id: <saml-dev.lists.oasis-open.org>
> >
> >>>1. http://portal.<dns_suffix>
> >>>2. https://inter-site-transfer.<dns_suffix>
> >>>3. https://receiver.<dns_suffix>
> >>>4. https://responder.<dns_suffix>
> >>>5. http://application.<dns_suffix>/application
> >
> >I forgot to mention this when I brought up port numbers. Our 
> >inter-site-transfer, receiver, and responder URLs have a path 
> >component, because they're all actually served by the same HTTP/SOAP 
> >server process. In a normal SelectAccess configuration, URLs 
> 2, 3, and 
> >4 look like:
> >
> >Inter-site transfer:
> >https://xxx.baltimore.com:9985/saml_out
> >
> >Receiver:
> >https://xxx.baltimore.com:9985/saml_in
> >
> >Responder:
> >https://xxx.baltimore.com:9985/saml_responder
> >
> >We can change the port number easily (as long as they're all 
> the same) 
> >and play DNS games to point all the names at the same actual 
> host, but 
> >we can't change the path.
> >
> > - irving -
> >
> >
> >-------------------------------------------------------------
> ----------
> >--------
> ----------------------------------
> >The information contained in this message is confidential and is 
> >intended for the addressee(s) only.  If you have received 
> this message 
> >in error or there are any problems please notify the originator 
> >immediately.  The unauthorised use, disclosure, copying or 
> alteration 
> >of this message is strictly forbidden. Baltimore 
> Technologies plc will 
> >not be liable for direct, special, indirect or consequential damages 
> >arising from alteration of
> the
> >contents of this message by a third party or as a result of 
> any virus 
> >being
> >passed on.
> > 
> >This footnote confirms that this email message has been swept for 
> >Content
> Security threats, including
> >computer viruses.
> >
> >http://www.baltimore.com
> >
> > 
> >This footnote confirms that this email message has been swept by
> >Baltimore MIMEsweeper for Content Security threats, including
> >computer viruses.
> >
> >----------------------------------------------------------------
> >To subscribe or unsubscribe from this elist use the subscription
> >manager: <http://lists.oasis-open.org/ob/adm.pl>
> 
> ______________________________________________________________
> __________ 
> Bhavna Bhatnagar                		Sun 
> Microsystems Inc.		 
> Identity Management group	 __o
> Tel: 408-276-3591              _`\<,_	
>                               (*)/ (*)  
> ______________________________________________________________
> __________ 
> 
> 
> 
> 
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>
> 



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC