Convert native Shibboleth SP installation to Shibboleth SP using InCommon metadata

Jason Johnson

unread,

Mar 15, 2012, 2:22:44 PM3/15/12

to us...@shibboleth.net

Hello,

I am wanting to convert my existing Shibboleth SP installation from a native (using local SP metadata file AND connecting to IDPs using local metadata files) to an InCommon/Shibboleth SP installation (with my SP metadata being pulled from InCommon). My biggest hurdle is I don't see where in the shibboleth2.xml file I need to specify that my SP metadata is to now be supplied remotely. I have seen this line mentioned a few times in other posts:

However, I was under the impression that this XML attribute was to tell Shibboleth how to interact with the IDPs. Do I have that wrong? Does it control both??

My end goal is the following:

1. Use my new InCommon SP metadata for all my connections
2. Use InCommon IDPs for those that are in InCommon
3. Use local IDP metadata files for those not in InCommon
4. All this using one Shibboleth installation.

Thanks,
Jason
--
To unsubscribe from this list send an email to users-un...@shibboleth.net

Jason Johnson

unread,

Mar 15, 2012, 4:09:58 PM3/15/12

to us...@shibboleth.net

Here is my sample shibboleth2.xml file



<SPConfig xmlns="urn:mace:shibboleth:2.0:native:sp:config" xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata"
    logger="syslog.logger" clockSkew="1800">

    
    <OutOfProcess logger="shibd.logger" />
    <InProcess logger="native.logger">
        <ISAPI normalizeRequest="true">
            
            <Site id="12345" name="sampleidp.nowhere.com"/>
        </ISAPI>

    </InProcess>

    
    <TCPListener address="127.0.0.1" port="12345" acl="127.0.0.1"/>
    <StorageService type="Memory" id="mem" cleanupInterval="900"/>
    <SessionCache type="StorageService" StorageService="mem" cacheTimeout="3600" inprocTimeout="900" cleanupInterval="900"/>
    <ReplayCache StorageService="mem"/>

    <RequestMapper type="Native">
        <RequestMap applicationId="default">
            <Host name="sampleidp.nowhere.com" applicationId="auth-sample">
                <Path name="secure" authType="shibboleth" requireSession="true" requireSessionWith="SampleIdP" />
            </Host>
        </RequestMap>
    </RequestMapper>

    
    <ApplicationDefaults id="default" policyId="default" REMOTE_USER="eppn"
        entityID="https://myspd.nowhere.com/shibboleth-sp"
        homeURL="https://myspd.nowhere.com/index.html">

        <Sessions lifetime="28800" timeout="3600" checkAddress="false" handlerURL="/Shibboleth.sso" handlerSSL="false">
            <SessionInitiator type="Chaining" Location="/Login" isDefault="false" id="SampleIdP" relayState="cookie" entityID="https://sampleidp.nowhere.com/idp/shibboleth">
                <SessionInitiator type="SAML2" acsIndex="1" template="bindingTemplate.html"/>
                <SessionInitiator type="Shib1" acsIndex="5"/>
            </SessionInitiator>

            
            <md:AssertionConsumerService Location="/SAML2/POST" index="1" Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"/>
            <md:AssertionConsumerService Location="/SAML/POST" index="6" Binding="urn:oasis:names:tc:SAML:1.0:profiles:browser-post"/>
            <Handler type="MetadataGenerator" Location="/Metadata" signing="false"/>
            <Handler type="Status" Location="/Status" acl="127.0.0.1"/>
            <Handler type="Session" Location="/Session"/>

            
            <LogoutInitiator type="Chaining" Location="/Logout">
                <LogoutInitiator type="SAML2" template="bindingTemplate.html"/>
                <LogoutInitiator type="Local"/>
            </LogoutInitiator>

            
            
        </Sessions>

        
        <Errors session="sessionError.html" metadata="metadataError.html" access="accessError.html" ssl="sslError.html"
            supportContact="root@localhost" logoLocation="/shibboleth-sp/logo.jpg" styleSheet="/shibboleth-sp/main.css"/>

        
        <!--

-->
        
        <TrustEngine type="ExplicitKey"/>
        <AttributeExtractor type="XML" path="attribute-map.xml"/>
        <AttributeResolver type="Query"/>
        <AttributeFilter type="XML" path="attribute-policy.xml"/>

        
        <CredentialResolver type="File" key="sp-key.pem" certificate="sp-cert.pem"/>

    <ApplicationOverride id="auth-sample" entityID="sampleidp.nowhere.com">
        <MetadataProvider type="XML" file="sampleidp-idp-metadata.xml"/>
    </ApplicationOverride>

    </ApplicationDefaults>


    
    <SecurityPolicies>
        <Policy id="default" validate="false">
            <Rule type="MessageFlow" checkReplay="true" expires="60"/>
            <Rule type="ClientCertAuth" errorFatal="true"/>
            <Rule type="XMLSigning" errorFatal="true"/>
        </Policy>
    </SecurityPolicies>

</SPConfig>

Cantor, Scott

unread,

Mar 15, 2012, 4:56:18 PM3/15/12

to Shib Users

> I am wanting to convert my existing Shibboleth SP installation from a native
> (using local SP metadata file AND connecting to IDPs using local metadata
> files) to an InCommon/Shibboleth SP installation (with my SP metadata being
> pulled from InCommon).

Your terminology is confusing here, but to start with, the SP doesn't use "SP metadata", only IdP metadata. So if you're saying you want the SP to be provisioning its IdPs from InCommon instead of a local file, I get it.

> My biggest hurdle is I don't see where in the
> shibboleth2.xml file I need to specify that my SP metadata is to now be
> supplied remotely.

Again, you don't use SP metadata. You specify IdP metadata remotely by using the XML provider with a url or uri attribute instead of a file or path attribute, and the various other trust related filtering you need.

> I have seen this line mentioned a few times in other posts:

InCommon has documentation that outlines how to provision the SP with their metadata, yes.

> However, I was under the impression that this XML attribute was to tell
> Shibboleth how to interact with the IDPs. Do I have that wrong? Does it
> control both??

Both what?

> 1. Use my new InCommon SP metadata for all my connections
> 2. Use InCommon IDPs for those that are in InCommon
> 3. Use local IDP metadata files for those not in InCommon
> 4. All this using one Shibboleth installation.

That just means you need multiple metadata sources, InCommon and others.

I think you're under the impression that the SP being "in InCommon" has some impact on its configuration as an SP, but it really doesn't.

-- Scott

Jason Johnson

unread,

Mar 16, 2012, 9:21:45 AM3/16/12

to Shib Users

Scott,

Thanks for the info. This is all confusing for me so I'm sure my use of terms or how I understand them may be incorrect.

I'm used to going to https://somesite/Shibboleth.sso/Metadata in order to generate the metadata for each client site for them to install on their IdP.

My confusion was that there is nothing that tells that to get things remotely. Or I was just doing it wrong.

And, yes, I am looking for multiple metadata sources - InCommon and others. What I would also like to do is the following:

1. Have both site1.somewhere.com and site2.somewhere.com use a common SP - sp.somewhere.com. So, in each site, they would have a login link that points to sp.somewhere.com/secure. This should bounce the user to the appropriate login for their site. Do I have that logic right?

Thanks,

Jason

--

…………………………
Jason Johnson
Terra Dotta, LLC
501 W. Franklin Street, Suite 105
Chapel Hill, NC 27516
Phone/Fax: 877-DOTTA-77 (877-368-8277) x111
http://TerraDotta.com

Register for Terra Dotta University in Charlotte, NC: April 18-20, 2012

Cantor, Scott

unread,

Mar 16, 2012, 11:07:35 AM3/16/12

to us...@shibboleth.net

On 3/16/12 9:21 AM, "Jason Johnson" <jas...@terradotta.com> wrote:
>I'm used to going to https://somesite/Shibboleth.sso/Metadata in order to
>generate the metadata for each client site for them to install on their
>IdP.
>My confusion was that there is nothing that tells that to get things
>remotely. Or I was just doing it wrong.

That has nothing to do with configuring your SP. That's your metadata. You
don't use your own metadata. I don't understand the rest of your comment.

>
>And, yes, I am looking for multiple metadata sources - InCommon and
>others.

Then just configure multiple sources.

> What I would also like to do is the following:
>

>1. Have both site1.somewhere.com <http://site1.somewhere.com> and
>site2.somewhere.com <http://site2.somewhere.com> use a common SP -
>sp.somewhere.com <http://sp.somewhere.com>.

> So, in each site, they would have a login link that points to

>sp.somewhere.com/secure <http://sp.somewhere.com/secure>. This should

>bounce the user to the appropriate login for their site. Do I have that
>logic right?

If you're talking about load balancing or something like that, then you
should read the topics on clustering. If you're talking about something
else, you've lost me.

Jason Johnson

unread,

Mar 16, 2012, 11:20:49 AM3/16/12

to Shib Users

Hmmm. Maybe I need a Shib configuration 101.

This is what I have.

1. One registered InCommon SP: msp.something.com
2. Multiple clients that need authentication: client1.something.com, client2.something.com, client3.something.com

The questions are:

1. Can I use the one SP for all three? And if so, how would a config look? I know I can register up to 50 SPs with my account but I already have more than 50 IdP clients.
2. If client1 and client2 are in InCommon and client3 is not, can I do the following:
a. Still use msp.something.com for ALL?
b. How would that look in a config?

Thanks,
Jason

Cantor, Scott

unread,

Mar 16, 2012, 11:32:28 AM3/16/12

to us...@shibboleth.net

On 3/16/12 11:20 AM, "Jason Johnson" <jas...@gmail.com> wrote:
>
>1. One registered InCommon SP: msp.something.com
>2. Multiple clients that need authentication: client1.something.com,
>client2.something.com, client3.something.com

If by client you mean literally a browser, that's not really anything the
configuration knows about. They're just clients. But I don't think you
mean client.

>The questions are:
>
>1. Can I use the one SP for all three? And if so, how would a config
>look? I know I can register up to 50 SPs with my account but I already
>have more than 50 IdP clients.

Now you're losing me again with your terminology. I don't understand what
you mean by client here, or what you mean by one SP.

InCommon has some limits on the number of distinct SP entityIDs you can
register, yes. Neither SP nor IdP are "clients" or have any impact on the
number of distinct users or clients you can offer service to.

You need to read the ApplicationModel topic in the wiki. The notion of an
entityID is a logical designation, not a physical one. It could mean one
server or a hundred and could mean one application or a hundred.

>2. If client1 and client2 are in InCommon and client3 is not, can I do
>the following:
> a. Still use msp.something.com for ALL?
> b. How would that look in a config?

I'm sorry, but I'm just not getting what you're asking. It seems to be
something so simple that I'm not getting it. Are you using the word client
to mean SP here?

What is "msp" for? Is that an SP? What is "ALL"? All what?

Maybe if you start by talking about what it is you're trying to protect,
without reference to SAML terms at all. What exactly is the application or
application(s) involved and what are the organizations that need to access
it?

Jason Johnson

unread,

Mar 16, 2012, 11:55:37 AM3/16/12

to Shib Users

Fair enough. My application allows institutions to have students apply for projects/classes online and staff/faculty are able to approve/deny and otherwise manage the application process. So, when I refer to clients, I'm speaking of the multiple institutions that can be identified by URL. All this requires student and staff members to login. Some institutions are now with InCommon - maybe half, 56. For the most part, all of them need to return the same data - first/last name, user name. Some require date of birth. The protected region allows them to see all their applications, personal data, and correspondence with the staff members involved.

I'm not sure how to put that in Shibboleth/InCommon speak where it makes sense.

Thanks,
Jason

----- Original Message -----
From: "Scott Cantor" <cant...@osu.edu>
To: us...@shibboleth.net
Sent: Friday, March 16, 2012 11:32:28 AM
Subject: Re: Convert native Shibboleth SP installation to Shibboleth SP using InCommon metadata

Cantor, Scott

unread,

Mar 16, 2012, 12:07:56 PM3/16/12

to us...@shibboleth.net

On 3/16/12 11:55 AM, "Jason Johnson" <jas...@gmail.com> wrote:

>Fair enough. My application allows institutions to have students apply
>for projects/classes online and staff/faculty are able to approve/deny
>and otherwise manage the application process.

Ok.

>So, when I refer to clients, I'm speaking of the multiple institutions
>that can be identified by URL.

Ok, those are simply the IdPs you want to support then. Identifying them
"by URL" is your choice, not a requirement. That's one way people get
around the discovery problem. But it gets very ugly if you insist on
creating dedicated hostnames for every IdP you support. Shibboleth simply
doesn't work well with that approach.

> All this requires student and staff members to login. Some
>institutions are now with InCommon - maybe half, 56.

Sure. Are you really finding that the others support SAML (but no via
InCommon) or just some other mechanism you offer?

>I'm not sure how to put that in Shibboleth/InCommon speak where it makes
>sense.

I'm now understanding your "client" terminology and why you were mapping
it to URLs.

The best way you could handle this is to *not* try and avoid the reality
that discovery of the IdP is simply necessary. You have one SP, one
entityID defined, and when a protected page is accessed you simply present
a discovery page to select the IdP. We offer tools for that, as do other
projects.

The next best way is that you could rely on part of the path or query
string to identify the IdP. That would still allow a single entityID and
vhost in the InCommon metadata, and you can tell the SP which IdP to use
based on the path using the entityID content setting in the RequestMap or
Apache command.

The worst way is to go down the road of registering multiple entityIDs
(one per IdP) or multiple ACS endpoints/vhosts (one per IdP). Of those two
choices, using one entityID and simply registering all the vhosts required
is far better than using multiple entityIDs.

In any case, none of this has anything to do with the physical deployment
choices of how many servers to use. That is discussed extensively in the
wiki.

Reply all

Reply to author

Forward