WARN: Unable to locate SAML 2.0 identity provider

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

WARN: Unable to locate SAML 2.0 identity provider

ctl-webmaster
Everyone:

As background, I am installing Shibboleth 2.0, using deployment instructions specific to Ohio State University (https://webauth.service.ohio-state.edu/~shibboleth/osu.html).

When I attempt to access protected content, I am able to enter my login information, but I am sent to OSU's error page rather than the desired content.  The shibdb.log has the following error:

"WARN Shibboleth.SessionInitiator.SAML2 [1]: unable to locate SAML 2.0 identity provider role for provider (urn:mace:incommon:osu.edu)"

According to the OSU deployment instructions:

"If you're getting metadata errors indicating the identity provider isn't supported, make sure you downloaded the InCommon-fedops.pem file mentioned earlier, as you'll need it at runtime to verify the signature on the InCommon metadata file that contains the OSU IdP's information."

I have the file specified, unfortunately, I don't understand the process, so I can't figure out why I'm getting an error.

I didn't want to fill this post with too much information, but if any additional information would be helpful, please let me know.  Any guidance would be greatly appreciated.

Thanks
Troy



Reply | Threaded
Open this post in threaded view
|

RE: WARN: Unable to locate SAML 2.0 identity provider

Cantor, Scott E.
[hidden email] wrote on 2009-01-21:
> When I attempt to access protected content, I am able to enter my login
> information, but I am sent to OSU's error page rather than the desired
> content.

OSU doesn't have an error page, so you'll have to provide more information.

>  The shibdb.log has the following error:
>
> "WARN Shibboleth.SessionInitiator.SAML2 [1]: unable to locate SAML 2.0
> identity provider role for provider (urn:mace:incommon:osu.edu)"

That isn't an ERROR (that's why it says WARN). It's nothing important.

> According to the OSU deployment instructions:
>
> "If you're getting metadata errors indicating the identity provider isn't
> supported, make sure you downloaded the InCommon-fedops.pem file mentioned
> earlier, as you'll need it at runtime to verify the signature on the
> InCommon metadata file that contains the OSU IdP's information."
>
> I have the file specified, unfortunately, I don't understand the process,
so
> I can't figure out why I'm getting an error.

Without knowing the error, it's impossible to say. If you're getting a
metadata lookup error, then your logs will either contain information during
startup explaining why the metadata isn't loading, or you'll need to start
over and follow the directions on the site more precisely. The OSU files
contain all the necessary settings to use and if you're not using them
exactly as described, it won't work.

-- Scott


Reply | Threaded
Open this post in threaded view
|

RE: WARN: Unable to locate SAML 2.0 identity provider

ctl-webmaster
Scott:

I have uninstalled and reinstalled Shibboleth 2.1, paying close attention to the deployment instructions.  I am encountering the same issue - when I attempt to access secure content I am able to log in, but then I am taking to a page titled "Web Login Service" and subtitled "Detected Back Button or Bookmark".  The web server has the current time, so I don't see it as being a time conflict.  The log entries are as follows:

shibd.log
2009-01-21 12:24:01 INFO Shibboleth.SessionCache [1]: new session created: ID (_103d6b8b5811835da9e5fa579f02f4c4) IdP (urn:mace:incommon:osu.edu) Protocol(urn:oasis:names:tc:SAML:1.1:protocol) Address (140.254.74.84)
2009-01-21 12:24:01 WARN Shibboleth.SessionInitiator.SAML2 [1]: unable to locate SAML 2.0 identity provider role for provider (urn:mace:incommon:osu.edu)
2009-01-21 12:24:01 INFO Shibboleth.SessionCache [1]: new session created: ID (_2668fdf9cad3331948d1958f4382b15d) IdP (urn:mace:incommon:osu.edu) Protocol(urn:oasis:names:tc:SAML:1.1:protocol) Address (140.254.74.84)
2009-01-21 12:24:01 WARN Shibboleth.SessionInitiator.SAML2 [1]: unable to locate SAML 2.0 identity provider role for provider (urn:mace:incommon:osu.edu)

transaction.log
2009-01-21 12:24:01 INFO Shibboleth-TRANSACTION [1]: New session (ID: _103d6b8b5811835da9e5fa579f02f4c4) with (applicationId: default) for principal from (IdP: urn:mace:incommon:osu.edu) at (ClientAddress: 140.254.74.84) with (NameIdentifier: QPPGV7MHAKMDZJNYOIJ7DENZAL5AELGIPO7IQCLR4PYXWRX6K3YOT3PAKLOFXTACSKTB4DOR5TMT44VYO73AU64U4F45GF23USKHHPOMIAA6E23GHR6A) using (Protocol: urn:oasis:names:tc:SAML:1.1:protocol) from (AssertionID: _e0b6c4888fd54cb2555e66d3b7f36b55)
2009-01-21 12:24:01 INFO Shibboleth-TRANSACTION [1]: Cached the following attributes with session (ID: _103d6b8b5811835da9e5fa579f02f4c4) for (applicationId: default) {
2009-01-21 12:24:01 INFO Shibboleth-TRANSACTION [1]:  KERBEROS-ID (1 values)
2009-01-21 12:24:01 INFO Shibboleth-TRANSACTION [1]:  sn (1 values)
2009-01-21 12:24:01 INFO Shibboleth-TRANSACTION [1]:  affiliation (3 values)
2009-01-21 12:24:01 INFO Shibboleth-TRANSACTION [1]:  givenName (1 values)
2009-01-21 12:24:01 INFO Shibboleth-TRANSACTION [1]:  WHOIS-ID (1 values)
2009-01-21 12:24:01 INFO Shibboleth-TRANSACTION [1]: }
2009-01-21 12:24:01 INFO Shibboleth-TRANSACTION [1]: New session (ID: _2668fdf9cad3331948d1958f4382b15d) with (applicationId: default) for principal from (IdP: urn:mace:incommon:osu.edu) at (ClientAddress: 140.254.74.84) with (NameIdentifier: ERP5DMODHIAQ5RDUIGH4WT3PAJGK6MKSRIGFAUOCU7MDEEKDKDHD5JNK3HFESHZST23WFJQNJGSCCDVQNPJHJ4ALVJUG6X6LZI6ZMJOVJ322IXYL3CHA) using (Protocol: urn:oasis:names:tc:SAML:1.1:protocol) from (AssertionID: _d843f35607c0f85cc439b60afae1959b)
2009-01-21 12:24:01 INFO Shibboleth-TRANSACTION [1]: Cached the following attributes with session (ID: _2668fdf9cad3331948d1958f4382b15d) for (applicationId: default) {
2009-01-21 12:24:01 INFO Shibboleth-TRANSACTION [1]:  KERBEROS-ID (1 values)
2009-01-21 12:24:01 INFO Shibboleth-TRANSACTION [1]:  sn (1 values)
2009-01-21 12:24:01 INFO Shibboleth-TRANSACTION [1]:  affiliation (3 values)
2009-01-21 12:24:01 INFO Shibboleth-TRANSACTION [1]:  givenName (1 values)
2009-01-21 12:24:01 INFO Shibboleth-TRANSACTION [1]:  WHOIS-ID (1 values)
2009-01-21 12:24:01 INFO Shibboleth-TRANSACTION [1]: }

Is there anything additional that I could provide that might be able to help you guide me as to what I am doing wrong?

Troy

________________________________________
From: Scott Cantor [[hidden email]]
Sent: Wednesday, January 21, 2009 10:47 AM
To: [hidden email]
Subject: RE: [Shib-Users] WARN: Unable to locate SAML 2.0 identity provider

[hidden email] wrote on 2009-01-21:
> When I attempt to access protected content, I am able to enter my login
> information, but I am sent to OSU's error page rather than the desired
> content.

OSU doesn't have an error page, so you'll have to provide more information.

>  The shibdb.log has the following error:
>
> "WARN Shibboleth.SessionInitiator.SAML2 [1]: unable to locate SAML 2.0
> identity provider role for provider (urn:mace:incommon:osu.edu)"

That isn't an ERROR (that's why it says WARN). It's nothing important.

> According to the OSU deployment instructions:
>
> "If you're getting metadata errors indicating the identity provider isn't
> supported, make sure you downloaded the InCommon-fedops.pem file mentioned
> earlier, as you'll need it at runtime to verify the signature on the
> InCommon metadata file that contains the OSU IdP's information."
>
> I have the file specified, unfortunately, I don't understand the process,
so
> I can't figure out why I'm getting an error.

Without knowing the error, it's impossible to say. If you're getting a
metadata lookup error, then your logs will either contain information during
startup explaining why the metadata isn't loading, or you'll need to start
over and follow the directions on the site more precisely. The OSU files
contain all the necessary settings to use and if you're not using them
exactly as described, it won't work.

-- Scott
Reply | Threaded
Open this post in threaded view
|

RE: WARN: Unable to locate SAML 2.0 identity provider

Cantor, Scott E.
> I have uninstalled and reinstalled Shibboleth 2.1, paying close attention
to
> the deployment instructions.

I didn't mean to reinstall, just to reapply the configuration changes.

> I am encountering the same issue - when I
> attempt to access secure content I am able to log in, but then I am taking
> to a page titled "Web Login Service" and subtitled "Detected Back Button
or
> Bookmark".

That's not a metadata error, it's looping. You're probably trying to use
http. You can't do that unless you change the configuration defaults, which
are for SSL only.

-- Scott


Reply | Threaded
Open this post in threaded view
|

RE: WARN: Unable to locate SAML 2.0 identity provider

ctl-webmaster
Scott:

On our site, some content is protected, but most of it isn't.  With Shibboleth 1.3, I added <Path> elements for the content I wanted to protect.  You advised me to add an attribute to the element:

"Now, if you want to allow use of http:// for data, you can do that. You just have to take the cookieProps attribute out of shibboleth.xml.  By default, it creates a secure cookie that is SSL only.
The more complex but more secure option is to leave it SSL only, but then require SSL for all folders you want to protect. . .

. . ., you can re-route requests to http:// to secure content using the shibboleth.xml RequestMap that you use to set up session policy. You add a redirectToSSL="443" to the Path element you want to redirect around. Any GET requests to that content will be redirected to https:// on the port you specify, which allows you to keep the cookieProps bit in place but also keep port 80 open.  But you should also use IIS to mark those folders as requiring SSL by checking the Require secure connection box in the directory security options in the IIS admin tool."

[The <Path> elements in my Shibboleth 1.3 configuration also have the attribute "exportAssertion='true'"; however, I can't find anything to indicate why I added that attribute.]

When I add the redirectToSSL attribute to the <Path> element in shibboleth2.xml, the Shibboleth 2.0 Daemon crashes and won't restart unless I remove the "redirectToSSL attribute.  Does Shibboleth 2.0 require some other configuration in order to require SSL for the folders we want to protect?

Troy

________________________________________
From: Scott Cantor [[hidden email]]
Sent: Wednesday, January 21, 2009 12:45 PM
To: [hidden email]
Subject: RE: [Shib-Users] WARN: Unable to locate SAML 2.0 identity provider

> I have uninstalled and reinstalled Shibboleth 2.1, paying close attention
to
> the deployment instructions.

I didn't mean to reinstall, just to reapply the configuration changes.

> I am encountering the same issue - when I
> attempt to access secure content I am able to log in, but then I am taking
> to a page titled "Web Login Service" and subtitled "Detected Back Button
or
> Bookmark".

That's not a metadata error, it's looping. You're probably trying to use
http. You can't do that unless you change the configuration defaults, which
are for SSL only.

-- Scott
Reply | Threaded
Open this post in threaded view
|

RE: WARN: Unable to locate SAML 2.0 identity provider

Cantor, Scott E.
CTL-Webmaster wrote on 2009-01-21:
> When I add the redirectToSSL attribute to the <Path> element in
> shibboleth2.xml, the Shibboleth 2.0 Daemon crashes and won't restart
> unless I remove the "redirectToSSL attribute.

That can't be why. If it's crashing, that's a whole other problem. If it's
not adopting the new configuration and/or just not starting up with it,
that's a syntax problem for which shibd.exe -check should report something
specific.

> Does Shibboleth 2.0
> require some other configuration in order to require SSL for the folders
> we want to protect?

No, it's the same syntax.
 
-- Scott


Reply | Threaded
Open this post in threaded view
|

RE: WARN: Unable to locate SAML 2.0 identity provider

ctl-webmaster
shibd.exe -check shows the error "Attribute 'redirectToSSL' is not declared for element 'Path'".  Is there a location I make this declaration in order to get the redirect to work?

________________________________________
From: Scott Cantor [[hidden email]]
Sent: Wednesday, January 21, 2009 3:19 PM
To: [hidden email]
Subject: RE: [Shib-Users] WARN: Unable to locate SAML 2.0 identity provider

CTL-Webmaster wrote on 2009-01-21:
> When I add the redirectToSSL attribute to the <Path> element in
> shibboleth2.xml, the Shibboleth 2.0 Daemon crashes and won't restart
> unless I remove the "redirectToSSL attribute.

That can't be why. If it's crashing, that's a whole other problem. If it's
not adopting the new configuration and/or just not starting up with it,
that's a syntax problem for which shibd.exe -check should report something
specific.

> Does Shibboleth 2.0
> require some other configuration in order to require SSL for the folders
> we want to protect?

No, it's the same syntax.

-- Scott
Reply | Threaded
Open this post in threaded view
|

RE: WARN: Unable to locate SAML 2.0 identity provider

Cantor, Scott E.
CTL-Webmaster wrote on 2009-01-21:
> shibd.exe -check shows the error "Attribute 'redirectToSSL' is not
declared
> for element 'Path'".  Is there a location I make this declaration in order
> to get the redirect to work?

You have a serious installation problem that is manifesting in a fashion
that is physically impossible based on what I know of the code. No copy of
the schema ever existed that could handle a 2.x config file while not
knowing about that attribute.

1. See what SHIBSP_SCHEMAS is set to in the environment when you run the
command.

2. Make sure you didn't install to drive D instead of drive C, or if you
did, make sure SHIBSP_SCHEMAS was set appropriately. Ideally, just don't
even try, use drive C.

3. Make sure you didn't overwrite anything in share/xml/ with old files.

-- Scott


Reply | Threaded
Open this post in threaded view
|

RE: WARN: Unable to locate SAML 2.0 identity provider

Cantor, Scott E.
In reply to this post by ctl-webmaster
Also as a concrete debugging measure it may be useful to explicitly examine
/opt/shibboleth-sp/share/xml/shibboleth/shibboleth-2.0-native-sp-config.xsd
for that attribute (just search for the name).

My assumption is that you'll find it, which is why I think the problem is
more with the process of finding the schema than the schema. But what is not
explainable is that if that were true, it would fail to even get that far.
That attribute alone would be the least of your problems.

-- Scott


Reply | Threaded
Open this post in threaded view
|

RE: WARN: Unable to locate SAML 2.0 identity provider

ctl-webmaster
When I initially started working on installing Shibboleth 2.0, I had to uninstall Shibboleth 1.3.  Before uninstalling, I copied c:/opt to the desktop to preserve the .pems and configuration files in case I ran into any trouble with the uninstall.  It appears to me that shibd.exe was accessing that directory instead of the new one created by the Shibboleth 2.0 install.  Once I removed the baackup from the desktop, the authentication process/redirect appears to be working.

I really appreciate your guidance.  Now, I have to deal with the REMOTE_USER header issue.

Thanks again,
Troy

________________________________________
From: Scott Cantor [[hidden email]]
Sent: Wednesday, January 21, 2009 4:13 PM
To: [hidden email]
Subject: RE: [Shib-Users] WARN: Unable to locate SAML 2.0 identity provider

Also as a concrete debugging measure it may be useful to explicitly examine
/opt/shibboleth-sp/share/xml/shibboleth/shibboleth-2.0-native-sp-config.xsd
for that attribute (just search for the name).

My assumption is that you'll find it, which is why I think the problem is
more with the process of finding the schema than the schema. But what is not
explainable is that if that were true, it would fail to even get that far.
That attribute alone would be the least of your problems.

-- Scott
Reply | Threaded
Open this post in threaded view
|

RE: WARN: Unable to locate SAML 2.0 identity provider

Cantor, Scott E.
> When I initially started working on installing Shibboleth 2.0, I had to
> uninstall Shibboleth 1.3.  Before uninstalling, I copied c:/opt to the
> desktop to preserve the .pems and configuration files in case I ran into
any
> trouble with the uninstall.  It appears to me that shibd.exe was accessing
> that directory instead of the new one created by the Shibboleth 2.0
install.
> Once I removed the baackup from the desktop, the authentication
> process/redirect appears to be working.

Hmm, some variant of that was probably involved, but it's a very peculiar
set of circumstances. It also must have been a badly out of date version of
1.3, FWIW.

> I really appreciate your guidance.  Now, I have to deal with the
REMOTE_USER
> header issue.

Not sure what you're referring to, but the SP determines REMOTE_USER using a
property in the ApplicationDefaults element that provides a list of
attribute names/ids to use in order of preference.

-- Scott