[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