Convert native Shibboleth SP installation to Shibboleth SP using InCommon metadata

[Cantor, Scott]

On 3/16/12 11:20 AM, "Jason Johnson" <jasonaj at 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?

-- Scott