Metadata format
Roy Spectech
roygspectech8 at gmail.com
Mon Sep 16 11:15:28 EDT 2013
Peter,
Thanks so much for answering our questions so well.
We thought, perhaps wrongly, that each "customer" should have their own
CERT, Key, and ACS lines. The reason for that is because, in this case,
there's are NOT separate VHOSTS for each customer. The application is
implemented in "paths" from the file tree:
/home/wwwroot/customer01\app01022
/home/wwwroot/customer02\app010310
[...etc...]
We have to have some way to segregate the customers as many have different
released variables (so different REMOTE_USER values), different Session
elements (lifetime/timeout lengths), etc.
So without VHOSTS, we thought each customer should have their own CERT and
key.
If that is not a good idea, or has no positive side, we'll drop it.
The second part of our question concerned the different ACS lines. We knew
they had to have different index numbers so as not to collide with the
existing ones.
So that means we have this as the "generated" metadata:
<md:EntityDescriptor xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata"
ID="_7f02024667d46287
aafdd4ecdfd0627d2010938b" entityID="https://apps.corp.com/Shibboleth.sso">
But the "customer" entityID are different:
entityID="https://apps.corp.com/customer01/Shibboleth.sso
and the associated ACS lines need to have unique indeces (example):
<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML
:2.0:bindings:HTTP-POST-SimpleSign" Location="
https://apps.corp.com/customer01/Shibboleth.sso/SAML2/POST-SimpleSign"
index="22"/>
That was the goal. Now, if we're way off here, then we'd love to see the
correct way.
But if we need to add multiple customer ACS lines, and each customer has a
unique entityID, CERT and Key, is there a way to combine those into one
file so we only have to publish one file.
Of course, another choice is to take the "Generated file" and just manually
adjust it:
So this (generated):
<md:EntityDescriptor xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata"
ID="_7f02024667d46287aafdd4ecdfd0627d2010938b" entityID="
https://apps.corp.com/Shibboleth.sso">
<md:ArtifactResolutionService
Binding="urn:oasis:names:tc:SAML:2.0:bindings:SOAP"
Location="https://apps.corp.com/Shibboleth.sso/Artifact/SOAP" index="1"/>
<md:SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:SOAP"
Location="https://apps.corp.com/Shibboleth.sso/SLO/SOAP"/>
<md:SingleLogoutService
Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect"
Location="https://apps.corp.com/Shibboleth.sso/SLO/Redirect"/>
<md:SingleLogoutService
Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
Location="https://apps.corp.com/Shibboleth.sso/SLO/POST"/>
<md:SingleLogoutService
Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact"
Location="https://apps.corp.com/Shibboleth.sso/SLO/Artifact"/>
<md:AssertionConsumerService
Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
Location="https://apps.corp.com/Shibboleth.sso/SAML2/POST" index="1"/>
<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML
:2.0:bindings:HTTP-POST-SimpleSign" Location="
https://apps.corp.com/Shibboleth.sso/SAML2/POST-SimpleSign" index="2"/>
<md:AssertionConsumerService
Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact"
Location="https://apps.corp.com/Shibboleth.sso/Shibboleth.sso/SAML2/Artifact"
index="3"/>
<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML
:2.0:bindings:PAOS" Location="https://apps.corp.com/Shibboleth.sso/SAML2/ECP"
index="4"/>
<md:AssertionConsumerService
Binding="urn:oasis:names:tc:SAML:1.0:profiles:browser-post"
Location="https://apps.corp.com/Shibboleth.sso/SAML/POST" index="5"/>
<md:AssertionConsumerService
Binding="urn:oasis:names:tc:SAML:1.0:profiles:artifact-01"
Location="https://apps.corp.com/Shibboleth.sso/SAML/Artifact" index="6"/>
Would become this:
<md:EntityDescriptor xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata"
ID="_7f02024667d46287aafdd4ecdfd0627d2010938b" entityID="
https://apps.corp.com/customer01/Shibboleth.sso">
<md:ArtifactResolutionService
Binding="urn:oasis:names:tc:SAML:2.0:bindings:SOAP"
Location="https://apps.corp.com/customer01/Shibboleth.sso/Artifact/SOAP"
index="1"/>
<md:SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:SOAP"
Location="https://apps.corp.com/customer01/Shibboleth.sso/SLO/SOAP"/>
<md:SingleLogoutService
Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect"
Location="https://apps.corp.com/customer01/Shibboleth.sso/SLO/Redirect"/>
<md:SingleLogoutService
Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
Location="https://apps.corp.com/customer01/Shibboleth.sso/SLO/POST"/>
<md:SingleLogoutService
Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact"
Location="https://apps.corp.com/customer01/Shibboleth.sso/SLO/Artifact"/>
<md:AssertionConsumerService
Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
Location="https://apps.corp.com/customer01/Shibboleth.sso/SAML2/POST"
index="1"/>
<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML
:2.0:bindings:HTTP-POST-SimpleSign" Location="
https://apps.corp.com/Shibboleth.sso/SAML2/POST-SimpleSign" index="2"/>
<md:AssertionConsumerService
Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact"
Location="https://apps.corp.com/customer01/Shibboleth.sso/Shibboleth.sso/SAML2/Artifact"
index="3"/>
<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML
:2.0:bindings:PAOS" Location="https://apps.corp.com/customer01/Shibboleth.
sso/SAML2/ECP" index="4"/>
<md:AssertionConsumerService
Binding="urn:oasis:names:tc:SAML:1.0:profiles:browser-post"
Location="https://apps.corp.com/customer01/Shibboleth.sso/SAML/POST"
index="5"/>
<md:AssertionConsumerService
Binding="urn:oasis:names:tc:SAML:1.0:profiles:artifact-01"
Location="https://apps.corp.com/customer01/Shibboleth.sso/SAML/Artifact"
index="6"/>
And we just send the second version to the various customer IdPs. Each one
get's a different "modified" IdP.
One way or the other, the endpoints have to be unique, and the IdPs need to
have the entityID, endpoints and metadata they need.
Eventually we'll be Federating so everything will have to be published
anyway. However, for now, our question revolved around exactly what to send
to the customer IdP servers.
Many thanks for all your help.
-- RGS
==================================
Roy G. Specter
roygspectech8 at gmail.com
========================================
On Sat, Sep 14, 2013 at 9:34 AM, Peter Schober
<peter.schober at univie.ac.at>wrote:
> * Roy Spectech <roygspectech8 at gmail.com> [2013-09-13 19:27]:
> > <md:EntityDescriptor xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata"
> > ID="_7f02024667d46287aafdd4ecdfd0627d2010938b" entityID="
> > https://app1.corp.com/Shibboleth.sso">
>
> Why did you add the "Shibboleth.sso" part there? The software didn't
> do that and it doesn't make much sense (the entityID is just a name,
> and as such doesn't have to map to a Shibboleth content handler).
>
> > </md:EntityDescriptor>
> >
> > This worked just fine with our partners and customers.
> >
> > Notice all the "<md: ... </md: pairs.
>
> The XML namespace used (and mapped to "md" above) is irrelevant here.
>
> > We then added the endpoints and CERT for one of new customers. We
> generated
> > their CERT pair with KEYGEN and their metadata file with METAGEN. When
> we
> > went to add this new meta file to the existing metadata file things blew
> up.
>
> If you you mean you concatenated the two XML files together you've
> generated non-well-formed (and schema invalid) XML. XML needs a common
> root element, you can't have <foo></foo><foo></foo> in a single instance.
>
> > <md:EntityDescriptor xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata"
> xmlns:
> > ds="http://www.w3.org/2000/09/xmldsig#" entityID="
> > https://app1.corp.com/customer2301/Shibboleth.sso">
>
> You should start by explaining your use case and why every "customer"
> would need a seperate entityID for your SP. If you did that before
> please provide a pointer to the archives.
>
> > </md:EntityDescriptor>
> >
> > This metadata also has the same <md:..</md pairs. However, none of our
> > partners or customers could import the new file. All complained that the
> > XML was rejected.
>
> If you have two seperate files and one validates and the other doesn't
> that would indicate the second one wasn't valid. So check for that,
> with the methods the software provides, or the list of tools the
> documentation mentions.
>
> > We're using the supplied tools (keygen.sh, metagen.sh) to create
> > metadatafiles for new customers (who appear as a different path in
> > our application tree). We want to add the customer endpoints and
> > entityID's to the main metadata file that we publish.
>
> If you want the content of both files within a single file (why?)
> you'd need to wrap them in a comon root element, an
> <EntitiesDescriptor> element in this case.
>
> > We know we have to care/craft/adjust/edit our metadata. Clearly the
> > supplied tools are just a starting point, but what guides to people
> > use to make sure the XML is correct for Shibboleth IdP's to
> > "consume." Is there a "generic metadata file" or documented guide
> > that we can refer to for this type of additional meta?
>
> https://wiki.shibboleth.net/confluence/display/SHIB2/MetadataForSP
>
> https://wiki.shibboleth.net/confluence/display/SHIB2/MetadataCorrectness
>
> -peter
> --
> To unsubscribe from this list send an email to
> users-unsubscribe at shibboleth.net
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://shibboleth.net/pipermail/users/attachments/20130916/102a3853/attachment.html
More information about the users
mailing list