Parsing the InCommon Metadata
Michael R. Gettes
I am trying to use simplesamlphp (SSP) as an SP within InCommon.
I have established a metadata refresh to automatically generate
the metadata files (saml2-idp-remote.php in particular) from the
InCommon metadata. I am attaching one item from what is generated.
I get the error:
Unable to locate metadata for 'internet2.edu' in set 'saml20-idp-
remote'.
0: /var/simplesamlphp/lib/SimpleSAML/Metadata/
MetaDataStorageHandler.php:309
(SimpleSAML_Metadata_MetaDataStorageHandler::getMetaData)
1: /var/simplesamlphp/lib/SimpleSAML/Metadata/
MetaDataStorageHandler.php:326
(SimpleSAML_Metadata_MetaDataStorageHandler::getMetaDataConfig)
2: /var/simplesamlphp/www/saml2/sp/initSSO.php:92 (N/A)
I have proven to myself the config is, in fact, being read by SSP but
SSP is not finding the metadata when I try to login from the IdP found
in
the attached file.
All this leads me to believe there may be something wrong with how the
InCommon metadata is getting parsed and then generated. Any assistance
is appreciated!
InCommon metadata is found at:
http://wayf.incommonfederation.org/InCommon/InCommon-metadata.xml
/mrg
Mads Freek Petersen
On 13/09/2009, at 20.04, Michael R. Gettes wrote:
> Unable to locate metadata for 'internet2.edu' in set 'saml20-idp-
> remote'.
and from the metadata:
> $metadata['urn:mace:incommon:internet2.edu'] = array (
> 'entityid' => 'urn:mace:incommon:internet2.edu',
The entityid is not 'internet2.edu' but
'urn:mace:incommon:internet2.edu'.
-Mads
get...@mit.edu
I changed entityid to 'internet2.edu' and this did not change things.
I changed the $metadata['urn:mace:incommon:internet2.edu'] to be
$metadata['internet2.edu'] and now I am getting
saml20-idp-remote/'internet2.edu': Could not retrieve the required
option 'SingleSignOnService'
This means SSP does not know how to parse the InCommon
metadata, yes? At least SSP natively does not know how
to do this... I am not sure how to configure SSP to do
the right thing here. I do not claim to know SSP very
well. I am using SSP because I want to use foodle.
Again, any help is greatly appreciated.
THANK YOU Mads!
/mrg
> --~--~---------~--~----~------------~-------~--~----~
> You received this message because you are subscribed to the Google
> Groups "simpleSAMLphp" group.
> To post to this group, send email to simple...@googlegroups.com
> To unsubscribe from this group, send email to simplesamlph...@googlegroups.com
> For more options, visit this group at http://groups.google.com/group/simplesamlphp?hl=en
> -~----------~----~----~----~------~----~------~--~---
>
Mads Freek Petersen
On 13/09/2009, at 22.59, get...@MIT.EDU wrote:
> saml20-idp-remote/'internet2.edu': Could not retrieve the required
> option 'SingleSignOnService'
The existence of both 1.1 and 2.0 metadata seems to confuse ssp as
SingleSignOnService is present in the metadata for shib13-idp-remote.
Try using the shib13-idp-remote metadata as saml20-idp-remote - except
for the scopes they are equal.
-Mads
Michael R. Gettes
only with shib13. I get farther - but, my metadata files all
have $metadata['urn:mace:incommon:blah'] as the index. I change
it to be just 'blah' striping away urn:mace:incommon and I get
farther - BUT, for example with MIT, I then get
Unable to locate metadata for 'https://idp.mit.edu/shibboleth' in set
'shib13-idp-remote'
So how is all this supposed to work? Am I blazing new ground
getting SSP to work with InCommon? Am I really the first? I
think SSP would be useful to InCommon - so fixing these problems
would be very helpful - especially when we all get to the point
of some form of inter-federation (don't laugh!). Just because
I am on western side of the pond doesn't mean I think shibboleth
is the only answer. I'd love to get this stuff to interoperate
but I am by no means an SSP expert. Any help appreciated!
Many thanks to Mads and the others replying privately thus far.
/mrg
Solberg Andreas Åkre
On 13. sep.2009, at 22:59, get...@MIT.EDU wrote:
> I changed entityid to 'internet2.edu' and this did not change things.
> I changed the $metadata['urn:mace:incommon:internet2.edu'] to be
> $metadata['internet2.edu'] and now I am getting
>
> saml20-idp-remote/'internet2.edu': Could not retrieve the required
> option 'SingleSignOnService'
Hi Michael. Great to see you on the list.
The metadata entry that you are trying to parse, is it the same
metadata that I see in the incommon metadata for the entity
'urn:mace:incommon:internet2.edu' ?
The simpleSAMLphp module 'saml2' that you are using, do support SAML
2.0 only, and do not support the shibboleth profile (SAML 1.1). The
entity you specify indicates in the @protocolSupportEnumeration that
it supports SAML 2.0, but simpleSAMLphp cannot find any Single Sign On
endpoints for use with SAML 2.0. If you take a look at the metadata,
you will see that the only SSO endpoint listed, is explicitly listed
as SAML 1.1 Shibboleth profile endpoint.
We are in the process of modularizing authentication, and the saml2
module was made first, with lack of SAML 1.1 support. The module
'saml' is in the works and will replace the 'saml2' module.
The plan is to release the new module before the UK Access Management
Federation event in Cardiff in November. I will, together with Olav,
do test this module against the UK federation with approx 700 Identity
Providers. This work involves:
- A plan on implementing support for the artifact binding for SAML 1.1
as it is so widely used in Shibboleth-focused federations.
- Easy and documented setup of metadata retrieval from a URL
- Discovery Service that scales to handle hundres of IdPs from
multiple federations. Tabbed interface with inline javascript search.
- Better support for combining the use of SAML 1.1 and SAML 2.0.
- Documented setup of simpleSAMLphp as an SP towards UK Access
Federation.
I assume InCommon is very much like UK Access Federation, and I would
be happy to do testing against InCommon as well. Do you reccomend some
persons to contact in order to test that? In example connecting the
Foodle service to InCommon?
In the meanwhile:
1) Most of the code of the saml module is available in simpleSAMLphp
trunk and can be tested, although it is work in progress.
2) If you want to use SimpleSAMLphp as an SP towards your IdP using
SAML 1.1, instead of using the saml2 module, use the www/shib13/*
files. And make sure that the IdP pushes attributes. Neither artifact
nor attribute pull is supported in simpleSAMLphp.
3) If you want to use SimpleSAMLphp as an SP towards your IdP using
SAML 2.0, make sure you got proper SAML 2.0 metadata for your IdP.
Andreas
Michael R Gettes
Yes, the metadata I am trying to parse (among the rest of InCommon metadata) is exactly what I sent along as in the InCommon XML and then what got produced as a sample (the internet2.edu attachment I sent). So, it would seem I am trying to do something currently on the edge. Bummer. I already submitted a change for my SP in InCommon to use the 1.1 metadata. I still fear this won’t work given my last email on this subject regarding the problem with the MIT IdP but I guess I will know more after 3pm EDT when the new InCommon metadata is posted. I have already switched to shib13 code based on the advice of Mads (THANK YOU Mads!). Overall you are replying to my earlier email on this topic and later I made further progress but I think your response is in line with other conclusions and is relevant in helping me plan a path forward.
As for testing with InCommon – I’m not sure – I guess it would be the usual shibboleth suspects but, if I am the only one trying to make SSP work with InCommon then I fear you will be stuck with me. As for foodle into InCommon – something we discussed on the COmanage call on Friday (leif was on it) we did consider the one global foodle but there are reasons for localized foodle as well. A CO is a closed community so foodle makes sense. It could be what we are trying to do with foodle is a way of getting foodle into InCommon or your global instance of foodle into InCommon is viable as well. No right answer here. I need to get foodle working for COmanage very quickly (i2 member meeting is in a few weeks) but I fear I will not make this deadline given what you have described. I appreciate your providing this information so I can plan on delivering other apps for i2 member meeting.
Thanks so much for the reply!
/mrg
Peter Schober
> As for testing with InCommon - I'm not sure - I guess it would be
> the usual shibboleth suspects but, if I am the only one trying to
> make SSP work with InCommon then I fear you will be stuck with me.
> call on Friday (leif was on it) we did consider the one global
> foodle but there are reasons for localized foodle as well. A CO is
> a closed community so foodle makes sense. It could be what we are
> trying to do with foodle is a way of getting foodle into InCommon or
> your global instance of foodle into InCommon is viable as well. No
> right answer here.
I think adding the global Foodle instance as an SP to InCommon is
probably best, since then Andreas (qua SP admin) can make adjustments
on the SSP side, as well as make sugestions if the InCommon metadata
indeed is constructed in a less-than-ideal way (as I read Andreas'
comment on protocol enumeration vs. provided endpoints).
OTOH it might not be the fastest route for you to get Foodle into
COmanage (but at least it would involve no work on your side ;)
-peter
Peter Schober
> I think adding the global Foodle instance as an SP to InCommon is
> probably best
I should add that the above was only meant as a way to get things to
work (with the side effect of Foodle then being usable throughout
InCommon), not to suggest whether COmanage should make use of the
public Foodle instance at foodle.feide.no for its own purposes.
-peter
Michael R. Gettes
/mrg