[Shib-Users] unable to locate SAML 2.0 identity provider role for provider
Matthew Bernhardt
I'm running into a problem getting an SP up and running, and have hit a wall
apparently. I've been lurking on this list, looking over the documentation
that I can find, and am making little progress - so I've resorted to posting
here. I hope that I haven't missed something too terribly basic.
The problem that I'm having is that, when the user returns from the sign on
page at my Identity Provider, they are greeted with a 403 error stating
"You don't have permission to access /Shibboleth.sso/SAML/POST on this
server."
The last few lines of the shibd.log file read:
2009-05-08 17:18:18 WARN Shibboleth.SessionInitiator.SAML2 [1]: unable to
locate SAML 2.0 identity provider role for provider
(urn:mace:incommon:osu.edu)
2009-05-08 23:22:55 WARN Shibboleth.SessionInitiator.SAML2 [1]: unable to
locate SAML 2.0 identity provider role for provider
(urn:mace:incommon:osu.edu)
2009-05-08 23:42:15 WARN Shibboleth.SessionInitiator.SAML2 [1]: unable to
locate SAML 2.0 identity provider role for provider
(urn:mace:incommon:osu.edu)
2009-05-08 23:51:23 WARN Shibboleth.SessionInitiator.SAML2 [1]: unable to
locate SAML 2.0 identity provider role for provider
(urn:mace:incommon:osu.edu)
2009-05-09 00:12:56 WARN Shibboleth.SessionInitiator.SAML2 [1]: unable to
locate SAML 2.0 identity provider role for provider
(urn:mace:incommon:osu.edu)
These timestamps correspond to my various logon attempts, one per attempt.
The access.log for this server records a single POST request for
/Shibboleth.sso/SAML/POST, which gets a 403 response. The ssl_request.log
also records two GET requests for the favicon.ico. I can provide those log
lines if necessary.
Consulting the sequence of events at http://switch.ch/aai/demo/2/expert.html
(which has been very helpful, btw) my diagnosis is that things are going
awry somewhere in step 9, immediately upon returning from the idp's logon
form. I know the idp to be working correctly, not least because I can log
onto other resources it is protecting around our campus.
When I examine the cookies present in my when I reach the 403 error, I see
two:
Name: _shibstate_3e0f9900
Value: http%3A%2F%2Fgeronimo.knowlton.ohio-state.edu%2Fsecure (i.e. the
resource I'm attempting to access)
Domain/Path: geronimo.knowlton.ohio-state.edu/
Name: SESS79023799e5b1d47a7e1fbb578e4ca5dd
Value: tmibe9057ivsl0ll97lrjsckk0
Domain/Path: .geronimo.knowlton.ohio-state.edu/
I'm going to keep looking over the documentation I can find, but I've spent
enough time on this now that I'm afraid I'm spinning my wheels - any
suggestions about where to look would be greatly appreciated. I hope I'm not
wasting everyone's time with a ridiculous question.
Thanks,
Matt
bernh...@osu.edu
Scott Cantor
> The problem that I'm having is that, when the user returns from the sign
on
> page at my Identity Provider, they are greeted with a 403 error stating
>
> "You don't have permission to access /Shibboleth.sso/SAML/POST on this
> server."
Then the SP isn't even functional yet. If it's IIS, your installation
apparently failed, and the ISAPI extension isn't enabled with execute
permission. If it's Apache, I'm at a loss short of explicit access control
rules you would have had to have created.
The first step of any installation is /Shibboleth.sso/Status. If that's not
returning the same error, I'd be surprised.
-- Scott
Matthew Bernhardt
Scott wrote:
> If it's Apache, I'm at a loss short of explicit access control
> rules you would have had to have created.
It's an Apache server, and your statement gave me a clue on how to proceed -
thanks! I'm eventually hoping to tie in with Drupal, for which there was a
series of mod_rewrite statements in httpd.conf that enabled clean URLs. I've
removed those, which helps me at least get a different error now. I've also
removed all Drupal files, leaving only an index.php and the /secure
directory.
With that changed, this is what I'm now seeing:
* https://localhost/Shibboleth.sso/Status is showing an XML document that
I'm still going through to understand what is there. I can post the contents
of that file if it would help, but I'm trying to keep these posts short.
* From a different computer, trying to access the /secure directory still
sends the user to the IDP. After providing username/password, however, the
user now lands at a message warning of a detected back button or bookmark.
The URL is that of my Identity Provider.
Querystring variables are shire, time, target, and providerId
Cookies present are shib_sp_fcc..., ship_sso_token, JSESSIONID, and
_saml_ipd
I'm a bit surprised at this step because as I understood the routing, once
the logon form is submitted to the IDP, the user is then sent back to the SP
and stays there? My interpretation is that something on my end is mistakenly
sending the user back to the IDP.
* The shibd.log file still is reporting warnings about being unable to
locate an SAML 2.0 identity provider role, but there is also an information
note about a new session being created. The last five lines are:
2009-05-10 00:52:17 INFO XMLTooling.StorageService : purged 20 expired
record(s) from storage
2009-05-10 01:02:37 WARN Shibboleth.SessionInitiator.SAML2 [7]: unable to
locate SAML 2.0 identity provider role for provider
(urn:mace:incommon:osu.edu)
2009-05-10 01:02:37 INFO Shibboleth.SessionCache [7]: new session created:
ID (_2efef9d12db2f69a2264ecbcfcdef07b) IdP (urn:mace:incommon:osu.edu)
Protocol(urn:oasis:names:tc:SAML:1.1:protocol) Address (164.107.45.189)
2009-05-10 01:02:37 WARN Shibboleth.SessionInitiator.SAML2 [7]: unable to
locate SAML 2.0 identity provider role for provider
(urn:mace:incommon:osu.edu)
2009-05-10 01:07:17 INFO XMLTooling.StorageService : purged 30 expired
record(s) from storage
* The transaction.log file also reports that a new session is being created.
The last four lines are:
2009-05-10 01:02:37 INFO Shibboleth-TRANSACTION [7]: New session (ID:
_2efef9d12db2f69a2264ecbcfcdef07b) with (applicationId: default) for
principal from (IdP: urn:mace:incommon:osu.edu) at (ClientAddress:
164.107.45.189) with (NameIdentifier:
V2XZ4PTKLGNYKM7WBSS6WFME6G2GXFJBCS7ANYIDAKESZROLCFJTXLX3EUFTOJJSLPTQNA43URHL
RFH2HHEMOQ26NFJJKNXOABKOMAMEDFHGVRYWMDVA) using (Protocol:
urn:oasis:names:tc:SAML:1.1:protocol) from (AssertionID:
_828dbde696600c2920ce5582a59ca079)
2009-05-10 01:02:37 INFO Shibboleth-TRANSACTION [7]: Cached the following
attributes with session (ID: _2efef9d12db2f69a2264ecbcfcdef07b) for
(applicationId: default) {
2009-05-10 01:02:37 INFO Shibboleth-TRANSACTION [7]: affiliation (4
values)
2009-05-10 01:02:37 INFO Shibboleth-TRANSACTION [7]: }
* One last thing - I don't think this should influence this error, but the
SP is currently using a self-signed certificate (which has expired while
I've been doing my testing). The user is warned by the browser and has to
explicitly accept/proceed, at which point they get to the "detected back
button" error. Obviously the certificate will be replaced before I move this
into production, but I wanted to mention it here in case that is more
significant than I'm assuming.
Thanks again for the assistance,
Matt
bernh...@osu.edu
Peter Schober
> * The shibd.log file still is reporting warnings about being unable to
> locate an SAML 2.0 identity provider role, but there is also an information
> note about a new session being created. The last five lines are:
> 2009-05-10 00:52:17 INFO XMLTooling.StorageService : purged 20 expired
> record(s) from storage
> 2009-05-10 01:02:37 WARN Shibboleth.SessionInitiator.SAML2 [7]: unable to
> locate SAML 2.0 identity provider role for provider
> (urn:mace:incommon:osu.edu)
> 2009-05-10 01:02:37 INFO Shibboleth.SessionCache [7]: new session created:
> ID (_2efef9d12db2f69a2264ecbcfcdef07b) IdP (urn:mace:incommon:osu.edu)
> Protocol(urn:oasis:names:tc:SAML:1.1:protocol) Address (164.107.45.189)
> 2009-05-10 01:02:37 WARN Shibboleth.SessionInitiator.SAML2 [7]: unable to
> locate SAML 2.0 identity provider role for provider
> (urn:mace:incommon:osu.edu)
It says Protocol(urn:oasis:names:tc:SAML:1.1:protocol). SAML1.1 != SAML2.0.
I'm not sure InCommon allows SAML2 endpoints yet, but in any case
there are no SAML2 endpoints in the InCommon metadata for
urn:mace:incommon:osu.edu right now.
How you got to using a SAML2 SessionInitiator with a SAML1 IdP I don't
know. What does your SessionInitiator in shibboleth2.xml look like?
Did you follow the instructions supplied by OSU?
https://authdev.it.ohio-state.edu/~shibboleth/deployment.html
cheers,
-peter
Scott Cantor
> * https://localhost/Shibboleth.sso/Status is showing an XML document that
> I'm still going through to understand what is there. I can post the
contents
> of that file if it would help, but I'm trying to keep these posts short.
It just reports on the state of the software. If it's returning XML and
reporting success, then it's fixed.
> * From a different computer, trying to access the /secure directory still
> sends the user to the IDP. After providing username/password, however, the
> user now lands at a message warning of a detected back button or bookmark.
Then you're looping, for which you'll find hundreds of messages discussion
the relevant issues. Could be lack of SSL, could be hostname issues.
> I'm a bit surprised at this step because as I understood the routing, once
> the logon form is submitted to the IDP, the user is then sent back to the
SP
> and stays there? My interpretation is that something on my end is
mistakenly
> sending the user back to the IDP.
That's correct.
> * The shibd.log file still is reporting warnings about being unable to
> locate an SAML 2.0 identity provider role, but there is also an
information
> note about a new session being created.
If the IdP wasn't blocking the loop, you'd see dozens being created as it
loops.
-- Scott