Shibbolet 2.4.3 Sp and SimpleSAMLphp as Idp - federation metadata

[Coeus]

Hi,

Is it possible for the simplesamlphp to produce a metadata as seen on
the given link below:
https://www.rediris.es/sir/shibtest1metadata.xml

I am having a problem with a federation (simplesamlphp set-up) where
they cannot provide such metadata where the idps and sps should be
listed.

We, as a service provider using Shibboleth 2.4.3, needs this type of
metadata to load the list of federations/idps from our WAYF
centralized discovery page.

I believe the metadata that I am referring to is mentioned in:
http://simplesamlphp.org/docs/1.9/simplesamlphp-idp section 8

Or if it's not possible, is there any way to link Shibboleth SP and a
simplesamlphp Idp to retrieve from the federation/idp metadata.

Please enlighten me on this.

Thanks!

[Olav Morken]

On Mon, May 21, 2012 at 23:18:52 -0700, Coeus wrote:
> Hi,
>
> Is it possible for the simplesamlphp to produce a metadata as seen on
> the given link below:
> https://www.rediris.es/sir/shibtest1metadata.xml

This is federation metadata, not metadata for individual IdPs and SPs.
While simpleSAMLphp can also be used to generate metadata for a
federation, that is a separate task from an IdP.

(You have not made this entirely clear, so I assume that this is a
federation with multiple IdPs. Other setups also exists, e.g. with a
proxy. In that case, the metadata for the federation is the metadata
of that central proxy.)

> I am having a problem with a federation (simplesamlphp set-up) where
> they cannot provide such metadata where the idps and sps should be
> listed.

And what can they provide?

> We, as a service provider using Shibboleth 2.4.3, needs this type of
> metadata to load the list of federations/idps from our WAYF
> centralized discovery page.
>
> I believe the metadata that I am referring to is mentioned in:
> http://simplesamlphp.org/docs/1.9/simplesamlphp-idp section 8

You can download metadata for the individual IdPs from that URL, but
not for the entire federation.

> Or if it's not possible, is there any way to link Shibboleth SP and a
> simplesamlphp Idp to retrieve from the federation/idp metadata.

If the federation does not provide a central URL where you can fetch
metadata, you can either point your Shibboleth SP to the URL of the
individual metadata entries, or you can download them manually and add
the downloaded files to your Shibboleth SP.


Best regards,
Olav Morken
UNINETT / Feide

[Coeus]

> This is federation metadata, not metadata for individual IdPs and SPs.
> While simpleSAMLphp can also be used to generate metadata for a
> federation, that is a separate task from an IdP.

Yes, it is a federation metadata and I'm working with a federation.
May I know how simpleSAMLphp can be used to generate federation
metadata?
or I would also appreciate if you may just provide a url where I can
read through.

> And what can they provide?

Apologies. What I really meant was that they cannot provide a complete
federation
metadata where our SP metadata should have been also included.

They have provided me these:
https://testidp.wayf.dk/saml2/idp/metadata.php
https://metadata.wayf.dk/birk-idp.xml - Bridged Interface for
Remotely Keyed IdPs

Thanks.

[Olav Morken]

On Tue, May 22, 2012 at 18:50:29 -0700, Coeus wrote:
> > This is federation metadata, not metadata for individual IdPs and SPs.
> > While simpleSAMLphp can also be used to generate metadata for a
> > federation, that is a separate task from an IdP.
>
> Yes, it is a federation metadata and I'm working with a federation.
> May I know how simpleSAMLphp can be used to generate federation
> metadata?
> or I would also appreciate if you may just provide a url where I can
> read through.

I think you are mixing things. That information is only useful to you
if you are going to generate your own metadata feed. But in any case,
you may take a look at these documents:

http://simplesamlphp.org/docs/1.9/simplesamlphp-automated_metadata
http://simplesamlphp.org/docs/1.9/aggregator:aggregator

> > And what can they provide?
>
> Apologies. What I really meant was that they cannot provide a complete
> federation
> metadata where our SP metadata should have been also included.

Not really related to simpleSAMLphp. Federation structure is
independent of the SP and IdP software used.

But do you really need the federation metadata to echo your SP metadata
back to you? Why?

> They have provided me these:
> https://testidp.wayf.dk/saml2/idp/metadata.php

This is one of their proxy-IdPs. There are multiple organizations
behind that IdP.

> https://metadata.wayf.dk/birk-idp.xml - Bridged Interface for
> Remotely Keyed IdPs

And these IdPs are bridges in fromt of the proxy. If I understand
correctly, they add scopes to the authentication request, so that the
requests are routed correctly through the central proxy-IdP.

[Coeus]

> I think you are mixing things. That information is only useful to you
> if you are going to generate your own metadata feed. But in any case,
> you may take a look at these documents:
>
> http://simplesamlphp.org/docs/1.9/simplesamlphp-automated_metadata
> http://simplesamlphp.org/docs/1.9/aggregator:aggregator
>

I think this is it, these are what exactly I need to know. Thanks.

> But do you really need the federation metadata to echo your SP metadata
> back to you? Why?

Yes. I would not be able to produce a list of federations/idps on our
"specific page" where different users are redirected to.

From my understanding, this is how the Shibboleth SP (via Centralized
Discovery Page/Legacy WAYF) works specific for the metadata lookup
only:

1. For example, a Shibboleth_SP, reads the federation metadata and
checks if its own metadata entry from the federation metadata exists.
2. If it does exists, Shibboleth_SP looks for the Shibboleth_IDP entry
from the federation metadata. This Shibboleth_IDP parameter came from
the "specific page".
3. Shibboleth_IDP then verifies the x509 certificate using the
federation metadata.

and so on...

As far as shibboleth is concerned, federated identity management
relies on this. This allows providers to locate each other and verify
their identity. Several major countries use the federated metadata
(where SPs and Idps entries are mixed)

> > They have provided me these:
> > https://testidp.wayf.dk/saml2/idp/metadata.php
>
> This is one of their proxy-IdPs. There are multiple organizations
> behind that IdP.
>

> > https://metadata.wayf.dk/birk-idp.xml- Bridged Interface for

> > Remotely Keyed IdPs
>
> And these IdPs are bridges in fromt of the proxy. If I understand
> correctly, they add scopes to the authentication request, so that the
> requests are routed correctly through the central proxy-IdP.

Yup. Thank you for explaining further. Now I get it.

[Olav Morken]

On Thu, May 24, 2012 at 01:06:21 -0700, Coeus wrote:
> Yes. I would not be able to produce a list of federations/idps on our
> "specific page" where different users are redirected to.
>
> From my understanding, this is how the Shibboleth SP (via Centralized
> Discovery Page/Legacy WAYF) works specific for the metadata lookup
> only:
>
> 1. For example, a Shibboleth_SP, reads the federation metadata and
> checks if its own metadata entry from the federation metadata exists.

Why does it care?

> 2. If it does exists, Shibboleth_SP looks for the Shibboleth_IDP entry
> from the federation metadata. This Shibboleth_IDP parameter came from
> the "specific page".

I.e. you have a page that links to the Shibboleth SP "start login"
hander?

> 3. Shibboleth_IDP then verifies the x509 certificate using the
> federation metadata.

The IdP may look into it's own metadata store (not the same metadata as
you download), in order to determine which certificate the SP uses to
sign authentication requests (if any), and the endpoints it should send
authentication responses and logout requests to.

> and so on...
>
> As far as shibboleth is concerned, federated identity management
> relies on this. This allows providers to locate each other and verify
> their identity. Several major countries use the federated metadata
> (where SPs and Idps entries are mixed)

But I do not think the SP actually cares about its own metadata in
these cases? Nor does it look at other SPs metadata?

If this is a problem for you, I think you should bring it up on the
shibboleth-users mailing list, since I do not see the connection to
simpleSAMLphp?

[Ian Young]

Just for the record...

On 24 May 2012, at 09:06, Coeus wrote:

> 1. For example, a Shibboleth_SP, reads the federation metadata and
> checks if its own metadata entry from the federation metadata exists.

The Shibboleth SP software does *not* read or require access to its own metadata.

> As far as shibboleth is concerned, federated identity management
> relies on this. This allows providers to locate each other and verify
> their identity. Several major countries use the federated metadata
> (where SPs and Idps entries are mixed)

Yes, several countries (including the UK, where I'm from) ship a combined aggregate containing all entities. This is *not* in general because entities need access to their own metadata, but because things are just simpler that way. It means you don't have to worry about entities that are not simply either IdPs or SPs, for example (an entity can be both an SP and an IdP, or it can be neither).

Central discovery services do in general need access to all entity metadata. IdPs are what are being selected, so that's obvious; a CDS that implements the discovery protocol also needs access to SP metadata so that it can validate the return address. And of course a central discovery service can use both IdP and SP MDUI metadata to enhance the experience.

-- Ian

[Coeus]

> > 1. For example, a Shibboleth_SP, reads the federation metadata and
> > checks if its own metadata entry from the federation metadata exists.
>
> Why does it care?

I have misunderstood how the shibboleth really works with regards to
the federation metadata. I think Ian have clearly explained it above.
Thanks to that.

> > 2. If it does exists, Shibboleth_SP looks for the Shibboleth_IDP entry
> > from the federation metadata. This Shibboleth_IDP parameter came from
> > the "specific page".
>
> I.e. you have a page that links to the Shibboleth SP "start login"
> hander?

We have a resource_page, for example which contains the protected
resources. You won't be able to access them until you login from your
Idp and of course until the Idp sends us the attributes and validate
them.

So this resource_page has a link named Institutional Log-in. Once the
user clicked that, will be redirected to our own CDS/WAYF page. The
user would then choose from the list of federations/idps and submit.

After that, the user will then be redirected to the appropriate Idp
login page which he/she selected from the CDS/WAYF page. If
successfully logged in, will be redirected once again back to the
resource_page but as an authorized user.

Now, this CDS/WAYF page is where I need to display a list of
Federations/Idps (two list boxes respectively). This is the problem -
I cannot load the list for that specific federation.

I am not sure at this point if the problem lies with how I configured
the CDS/WAYF page so it looks like the Shibboleth is "reading" from
the federation metadata or I wonder if sites/sitesList has something
to do with this.

Anyway, this is far from the simpleSAMLphp topic. Just wanted to
clarify things.

Appreciate your help Olav.

[Coeus]

> The Shibboleth SP software does *not* read or require access to its own metadata.

Thanks for clarifying. Appreciate this.

> Central discovery services do in general need access to all entity metadata.  IdPs are what are being selected, so that's obvious; a CDS that implements the discovery protocol also needs access to SP metadata so that it can validate the return address.  And of course a central discovery service can use both IdP and SP MDUI metadata to enhance the experience.

So the problem lies with the CDS/WAYF or the logic behind that the
previous developer applied on it? I guess, maybe...

But hey Ian, thanks for the help and the clarifications.

For the meantime, I need to research more about the CDS/WAYF.

Thanks for the help guys.