[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [security-services] fta: RE: Liberty's Provider Metadata applicabilityto SAML
fta (for the archives), this is the relevant discussion btwn Prateek & myself
that preceeded the issuance of draft-sstc-meta-data-00.doc
JeffH
-------- Original Message --------
Subject: RE: Liberty's Provider Metadata applicability to SAML ~~
Date: Wed, 30 Oct 2002 13:32:16 -0500
From: "Mishra, Prateek" <pmishra@netegrity.com>
To: "'Jeff.Hodges@sun.com'" <Jeff.Hodges@Sun.COM>
Jeff,
Here are my responses to your comments. Let me know if they
make sense, and, if so, we can move on to next steps. Sounds
like we should simply create the appropriate schema and present
to the group. If so, I can take a crack at it and send
for your review. But first
lets make sure we agree about the basics.
- prateek
----------------------------------------------------------------
>>
>>My conclusion is, assuming the below is correct, that the
>>Liberty Provider
>>Metadata _concept_ is likely nominally useful in the SAML
>>context -- ie having
>>an XML schema to describe SAML-specific provider metadata is
>>a nominal win for
>>all the usual reasons XML-ifying data is a nominal win.
>>
Agreed, the Liberty Provider Metadata is suggestive and quite
helpful but cannot be used exactly as found in Section 4 of
the "Liberty Protocols and Schemas Specification". I would propose
that we use the Liberty schema as a guide to figure out the
meta-data relevant to both artifact and POST profiles. This also
seems to be the intent of your proposal.
>>However, the Liberty Provider Metadata _format itself_ is
>>likely not directly
>>useful in the SAML context, because as-is the SAML needs and
>>the Liberty needs
>>aren't congruent, rather they're only slightly intersecting.
>>This is largely
>>because the Liberty protocol/profile messages are different
>>from the SAML ones,
>>so one wouldn't want to publish one's SAML-specific info using a
>>Liberty-specific schema (and vice-versa). Also, Liberty
>>requires several more
>>metadata items than SAML-only provider metadata. So overall,
>>we'd likely want
>>different metadata schemas for Liberty and SAML, tho the
>>Liberty one can be
>>leveraged to create the SAML one. A first step towards that
>>is below, tho the
>>element names probably need to be changed (tho one could
>>address this with
>>xmlnamespace magic).
>>
>>what do you think?
>>
>>JeffH
>>-----
>>
>>In looking at [1]...
>>
>>[saml-dev] Compiled configurations for Munich
>>http://lists.oasis-open.org/archives/saml-dev/200209/msg00024.html
>>
>>..from which I've extracted this example entry [2]..
>>
>>01> -----------------------------------------------------------
>>02> ### [4] Entegrity
>>03>
>>04> Machine Names/IP Addresses:
>>05> - saml.entegrity.com 192.168.16.41
>>06>
>>07> URLs:
>>08> - Portal: https://saml.entegrity.com:8002/index.jsp
>>09> - Application: http://saml.entegrity.com:8001/application/zoo.jsp
>>10> - Inter-Site: https://saml.entegrity.com:8002/InterSiteTransfer
>>11> - Receiver: https://saml.entegrity.com:8002/ArtifactConsumer
>>12> - Responder: https://saml.entegrity.com:8004/Responder
>>13>
>>14> SourceID:
>>15> - Hex: 9913544d409105cd834218018f8d6bed0c845267
>>16> - B64: mRNUTUCRBc2DQhgBj41r7QyEUmc=
>>17>
>>18> Issuer: www.entegrity.com
>>19>
>>20> -----------------------------------------------------------
>>
>>
>>..and comparing both of the above with this illustration of the
>>browser-artifact SSO profile [3] (also attached)..
>>
>>http://www.oasis-open.org/committees/security/outreach/hodges-
>>web-browser-profile-diagram-2002-10-28.pdf
>>
>>
>>..I have these questions..
>>
>>
>>1. are the "Portal" and "Application" entries in [2] (lines 8
>>& 9) simply the
>>addresses of applications that're running at
>>"http://d.com/target/"; in [3]?
>>(I'm thinking yes)
Yes. The portal part is completely informational. The Application URL
corresponds to http://d.com/target component. In the demo we did not
implement steps 1-3 of your flow, so we needed to "hard-code" the TARGET
values. So we do not need to include these values in the meta-data.
>>
>>2. The "Inter-site" entry in [2] corresponds to
>>"http://s.com/stuff/"; in [3],
>>yes?
Yes.
>>
>>3. The "Receiver" entry in [2] corresponds to
>>"http://d.com/AssnCnsm/"; in [3],
>>yes?
Yes. (But not that this is the artifact receiver URL).
>>
>>4. The "Responder" entry in [2] corresponds to the url value
>>the request in
>>Step 6 in [3] (which is step 4 in cs-sstc-bindings-01) is
>>directed to, yes?
>>
>>
Yes.
>>
>>Assuming I have the above correct, then given the provider
>>metadata in ..
>>
>>http://www.projectliberty.org/specs/liberty-architecture-proto
>>cols-schemas-v1.0.pdf
>>http://www.projectliberty.org/specs/liberty-architecture-proto
>>cols-schemas-v1.0-errata-00.xsd
>>
>>..the ~nominal~ one-for-one correspondences appear to be
>>these (in xml schema
>>format with extraneous, non-corresponding element definitions
>>elided; plus with
>>ones with questions highlighted)..
>>
>>
>> <!-- Begin provider metadata schema -->
>> <complexType name="ProviderDescriptorType">
>> <sequence>
>>
>> [ <element ref="ds:KeyInfo" minOccurs="0"/> ? ]
>> <!-- no item in [2] for cert (ie public key) exchange,
>> but it looks like it'd be possible to simply add it. -->
Information about the trust relationship between the source and destination
sites was not explicitly included in the demo document except to say
that bilateral authentication over HTTPS was assummed.
Information about the certificates (including root CAs) used at both ends
was provided "informally" by Irving (Baltimore implemented the CA).
We need to capture this information. It would have the following structure:
POST Profile
- <element ref="ds:KeyInfo"> ---- certificate/certificate chain for
used by source site for signing
Artifact Profile
- SAML Protocol Binding URI ---- identify protocol binding is
used to resolve artifact(s);
remaining fields are relevant
- Trust Relationship for HTTP Binding Only
(a) HTTP
(c) HTTP + Basic
(name/password pair)
(d) HTTPS + Basic
(name/password pair,
use <element ref="ds:KeyInfo"> for server-side cert)
(e) HTTPS server-side auth only
(use <element ref="ds:KeyInfo"> for server-side cert)
(f) Bilateral HTTPS with client-side certificate
(two instances of <element ref="ds:KeyInfo">)
>> <element name="SoapEndpoint" type="anyURI" minOccurs="0"/>
>> <!-- essentially corresponds to "Responder" in [2].
>> it's only "essentially" because in the Liberty
>> protocol/profile, the msg returned as a result of
>> dereferencing the artifact is different than the
>> SAML browser artifact profile -- a Liberty-flavored
>> authentication assertion is returned. -->
>>
>> </sequence>
>> </complexType>
Artifact Profile
- corresponds to Responder in [2]
POST Profile
- not used
>>
>> <element name="SPDescriptor" type="lib:SPDescriptorType"/>
>> <complexType name="SPDescriptorType">
>> <complexContent>
>> <extension base="lib:ProviderDescriptorType">
>> <sequence>
>>
>> <element name="AssertionConsumerServiceURL" type="anyURI"/>
>> <!-- essentially corresponds to "Receiver" in [2].
>> it only "essentially corspnds" because the
>>Liberty protocol
>> messages are different from the
>>corresponding SAML ones
>> and thus the code waiting for input to be
>>sent to this
>> url is different between the Liberty and SAML cases.
>> Also the reply msg differs. -->
>>
This name is somewhat misleading for the artifact profile, becuz this
refers to an artifact receiver (or consumer). It IS the correct name in the
POST profile. So maybe we split this into:
<element name = "ArtifactReceiverURL" type="URL"/>
OR
<element name="AssertionConsumerServiceURL" type="URL"/>
>> [ <element name="AuthnRequestsSigned"
>>type="boolean"/> ? ]
>> <!-- doesn't directly correspond because there
>>isn't provision
>> in the SAML browser artifact profile for signing the
>> request sent to the inter-site transfer service. -->
>>
>>
>> </sequence>
>> </extension>
>> </complexContent>
>> </complexType>
Not relevant to either profile. The artifact profile does not require
signing,
while the POST profile always requires signing of the response (the outer
envelope
holding the assertions).
>> <element name="IDPDescriptor" type="lib:IDPDescriptorType"/>
>> <complexType name="IDPDescriptorType">
>> <complexContent>
>> <extension base="lib:ProviderDescriptorType">
>> <sequence>
>>
>> <element name="SingleSignOnServiceURL" type="anyURI"/>
>> <!-- essentially corresponds to "Inter-site" in [2].
>> it only "essentially corspnds" because the
>>Liberty protocol
>> messages are different from the
>>corresponding SAML ones
>> and thus the code waiting for input to be
>>sent to this
>> url is different between the Liberty and SAML cases.
>> Also the reply msg differs. -->
>>
>>
Both the artifact and POST profiles use the inter-site transfer
URL. We should simply rename to reflect that usage:
<element name="InterSiteTransferURL" type="anyURI"/>
Other items included in the configuration but not found in Liberty:
SourceID, Issuer Name.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC