[Shib-Users] Shibboleth handler invoked at an unconfigured location
Achugatla, Vijay K. (LNG-CON)
I am getting following error from SP 2.1 “Shibboleth handler invoked at an unconfigured location” in the browser
I found some info from archive and tried those options. I tried using /Login and /WAYF in the initiator but still got the same error
shibsp::ConfigurationException
The system encountered an error at Mon May 11 23:56:27 2009
To report this problem, please contact the site administrator at
Please include the following message in any email:
shibsp::ConfigurationException at (http://dvc7617.lexisnexis.com:25007/SHIRE/WAYF)
Shibboleth handler invoked at an unconfigured location.
Is there any other config that I need to change along with handlerURL?
Thanks,
Vijay
Peter Schober
> shibsp::ConfigurationException at
> (http://dvc7617.lexisnexis.com:25007/SHIRE/WAYF)
>
> Shibboleth handler invoked at an unconfigured location.
>
> Is there any other config that I need to change along with handlerURL?
The default handlerURL is /Shibboleth.sso, so the Login handler would
be at /Shibboleth.sso/Login, the Status handler at
/Shibboleth.sso/Status etc.
Besides checking your config (only you know what you've changed) you
can try to set native.logger to DEBUG and check native.log (note that
this log needs to be writeable by the webserver, as well as the
directory it's in. At least the RPM does not do this for you).
-peter
Scott Cantor
> Is there any other config that I need to change along with handlerURL?
Please don't try to change the handlerURL. That's not a productive thing to
do.
-- Scott
Achugatla, Vijay K. (LNG-CON)
I changed the handlerURL URL to /Shibboleth.sso as suggested but I still have issues
Initially I did not mention the Location in the SessionInitiator and I was getting the error message “Shibboleth handler invoked at an unconfigured location”. Then I updated the SessionInitiator with Location (Location="/WAYF”). And this time I am getting the message
shibsp::ConfigurationException at (http://dvc7617.lexisnexis.com:25007/Shibboleth.sso/WAYF)
Target resource was not an absolute URL.
Below is the Sessions configuration from shibboleth2.xml
<Sessions
lifetime=" 28800 " timeout="3600" checkAddress="false"
handlerURL="/ Shibboleth.sso" handlerSSL="false" cookieName="sciencedirect"
cookieProps="; path=/; domain=.lexisnexis.com" >
<SessionInitiator type="WAYF" isDefault="true" Location="/WAYF"
URL="http://dvc7632:25924/science/externallogin">
</SessionInitiator>
</Sessions>
I was looking at the AbstractSPRequest.cpp file and analyzing the code that throws this error message
If I understand correctly, the resource can not be bull because the getRequestURL() method returns “://” at the worst case. So the condition
(!m_handlerURL.empty() && resource && !strcmp(getRequestURL(),resource)) is failing because m_handlerURL.empty() is empty (that means handler URL is empty). Please correct me if my understanding is wrong.
const char* AbstractSPRequest::getHandlerURL(const char* resource) const
{
if (!resource)
resource = getRequestURL();
if (!m_handlerURL.empty() && resource && !strcmp(getRequestURL(),resource))
return m_handlerURL.c_str();
#ifdef HAVE_STRCASECMP
if (!resource || (strncasecmp(resource,"http://",7) && strncasecmp(resource,"https://",8)))
#else
if (!resource || (strnicmp(resource,"http://",7) && strnicmp(resource,"https://",8)))
#endif
throw ConfigurationException("Target resource was not an absolute URL.");
const char* AbstractSPRequest::getRequestURL() const
{
if (m_url.empty()) {
// Compute the full target URL
int port = getPort();
const char* scheme = getScheme();
m_url = string(scheme) + "://" + getHostname();
if ((!strcmp(scheme,"http") && port!=80) || (!strcmp(scheme,"https") && port!=443)) {
ostringstream portstr;
portstr << port;
m_url += ":" + portstr.str();
}
m_url += m_uri;
}
return m_url.c_str();
}
But I have given handlerURL="/ Shibboleth.sso" in the shibboleth2.xml file.
Does it mean that its not able to find the handlerURL in the shibboleth2.xml file?. Or it is looking for handlerURL at somewhere else?
Also, what does this error message “Target resource was not an absolute URL” try to convey? Does it mean it is not able to find the targetURL? Or the targetURL is there but broken? Or is it looking for something else?
Any help would be appreciated. Let me know if you need any more details
Thanks,
Vijay
Scott Cantor
> And this time I am getting the message
That usually means you've confused it in some way by changing something to
an invalid value.
> handlerURL="/ Shibboleth.sso"
If that space in there is actually there, it's wrong. You can't have a space
inside there. I wouldn't be too shocked if that breaks in an unpredictable
way.
> Also, what does this error message "Target resource was not an absolute
URL"
> try to convey? Does it mean it is not able to find the targetURL? Or the
> targetURL is there but broken? Or is it looking for something else?
It probably means the code is doing something it was never intended to do,
and it just happened to fail with that message. It rarely means anything
useful, it normally shows up because of bugs caused by inputs that weren't
anticipated and aren't being handled gracefully.
I can't suggest anything else because I don't know what you're doing. Is
this a protected resource, or a lazy session redirection? If the latter,
what does the redirect include on the query string?
-- Scott
Scott Cantor
>> handlerURL="/ Shibboleth.sso"
> If that space in there is actually there, it's wrong. You can't have a
> space inside there. I wouldn't be too shocked if that breaks in an
> unpredictable way.
Well, apparently not, that seems to actually work, kind of. It's still a
terribly bad idea, but it doesn't cause that error.
My best guess is it's something to do with all those cookie changes you're
trying to make. I don't think changing the cookieName works well, and it may
not work at all, so I would probably start there and undo it.
-- Scott
Scott Cantor
that
> throws this error message
>
> If I understand correctly, the resource can not be bull because the
> getRequestURL() method returns "://" at the worst case. So the condition
> (!m_handlerURL.empty() && resource && !strcmp(getRequestURL(),resource))
is
> failing because m_handlerURL.empty() is empty (that means handler URL is
> empty). Please correct me if my understanding is wrong.
Sorry, I didn't answer this. No, you're not understanding it.
The error itself is related to what it thinks the protected resource URL is.
This almost has to be a lazy session request, in which case the problem may
be that you handed it a broken target parameter, or that you screwed with
the cookie handling enough so that a relay state target value couldn't get
turned back into a URL properly.
It all comes down to what you're trying to do, which is not something I can
figure out from your question.
-- Scott
Achugatla, Vijay K. (LNG-CON)
I am trying to setup Shib SP2.1 and getting “Shibboleth handler invoked at an unconfigured location.” Error on the browser when I try to authenticate from IDP1.3. When this message is displayed the URL in the browser is http://dvc7617.lexisnexis.com:25007/Shibboleth.sso
I attached a zip file that has the configuration file (shibboleth2.xml) that I am using, the IDP log messages and the messages from SP logs. These are the only messages that I see when I try to authenticate from IDP.
I noticed that It’s always taking the default Sessions configurations. It’s not taking the configurations based on applicationId even though I have given the host details in which my SP is running
Could you please have a look at the config file and the logs and tell me if something is missing or incorrect
Thanks,
Vijay
Scott Cantor
> I noticed that It's always taking the default Sessions configurations.
It's
> not taking the configurations based on applicationId even though I have
> given the host details in which my SP is running
Because the port is non-standard and you don't have that in the host
mapping.
> Could you please have a look at the config file and the logs and tell me
if
> something is missing or incorrect
Aside from the missing custom port, you have an override here for what seems
to be no reason I can come up with, since you're just vhosting. The override
uses the same handlerURL and a bunch of dangerous cookie options you should
avoid in 99% of cases.
So my suggestion to start with is to undo all that and stay with the
defaults whereever you can.
It's also got a broken SessionInitiator that will only support SAML 1.1
using a WAYF (so even if you tell it the entityID to use, it won't honor
it). An initiator chain should always preface the WAYF or DS with the Shib1
and SAML2 handlers, which is why those are the defaults.
Lastly, the IdP log shows it attempting to return the response to
/SHIRE/WAYF, not the proper location at the SP, so something is wrong
elsewhere, be it a link or a metadata issue.
-- Scott
Achugatla, Vijay K. (LNG-CON)
Scott,
I have made the below changes as suggested. Also attached the files
Included the custom port in Host mapping
Removed the configurations related to cookie
Removed the ApplicationOverride
Corrected the response location that IDP was trying to return the response
I am still getting the same message “Shibboleth handler invoked at an unconfigured location.”
If I understand correctly the handler is the combination of http:// + Host + port + handlerURL + SessionInitiator Location. Correct me if this is wrong
In my case
Host - dvc7617.lexisnexis.com
Post – 25007
handlerURL - /Shibboleth.sso
SessionInitiator Location - /Login
So the handler is http://dvc7617.lexisnexis.com:25007/Shibboleth.sso/Login. When I use this, it is taking me beck to the IDP selection page. And when I use http://dvc7617.lexisnexis.com:25007/Shibboleth.sso then it is giving “Shibboleth handler invoked at an unconfigured location.”
I am confused about which one is the correct handler?
I captured the below URL when IDP was redirecting to the SP. The server cpc1764 is where the IDP is present. Any chance that the URL is not formed correctly?
Thanks,
Vijay
Scott Cantor
> + port + handlerURL + SessionInitiator Location. Correct me if this is
wrong
The handler location depends on the handler. For a SessionInitiator, yes,
that's the location. For something else, it's not. In no case is
/Shibboleth.sso a valid location.
> So the handler is
http://dvc7617.lexisnexis.com:25007/Shibboleth.sso/Login.
> When I use this, it is taking me beck to the IDP selection page.
It will do whatever the SessionInitiator is defined to do.
> And when I
> use http://dvc7617.lexisnexis.com:25007/Shibboleth.sso then it is giving
> "Shibboleth handler invoked at an unconfigured location."
Which is competely normal.
> I captured the below URL when IDP was redirecting to the SP. The server
> cpc1764 is where the IDP is present. Any chance that the URL is not formed
> correctly?
It's not formed correctly, and it didn't come from the SP because there is
no such ACS handler defined.
-- Scott
Achugatla, Vijay K. (LNG-CON)
Scott,
It’s good to know that "Shibboleth handler invoked at an unconfigured location." Is normal for http://dvc7617.lexisnexis.com:25007/Shibboleth.sso URL
As per the session initiator I defined (as given below), it will redirect the User to the URL provided where he can select an IDP from the list of available IDPs. So the session initiator handler would be http://dvc7617.lexisnexis.com:25007/Shibboleth.sso/WAYF.
<SessionInitiator type="Chaining" Location="/Login" relayState="cookie" isDefault="true">
<SessionInitiator type="SAML2" defaultACSIndex="1"
acsByIndex="false" template="bindingTemplate.html"/>
<SessionInitiator type="Shib1" defaultACSIndex="5"/>
<SessionInitiator type="WAYF" defaultACSIndex="5" URL="http://dvc7632.lexisnexis.com:25929/science/externallogin"/>
</SessionInitiator>
Since the session initiator is defined to redirect to the IDP selection page, it is trying to do the same when IDP is trying to access the http://dvc7617.lexisnexis.com:25007/Shibboleth.sso/WAYF URL. Is this correct?
So, the IDP should be configured such a way that it should not access the session initiator handle because that will redirect back to the WAYF URL (IDP selection page). Is this correct?
In that case what is the URL/handler that IDP is supposed to return the response? And from there how does InProcess to OutOfProcess communication happens? Do I need to configure anything explicitly to tell InProcess to access particular location at OutOfProcess?
You mentioned that the URL above is not formed correctly, and it didn't come from the SP because there is no such ACS handler defined. I dint understand this statement completely. Could you tell me which part of the URL is not correct as per you? I am not sure but I think this URL is formed at the IDP side
Thanks,
Vijay
-----Original Message-----
From: Scott Cantor [mailto:cant...@osu.edu]
Sent: Tuesday, May 26, 2009 2:54 PM
To: shibbole...@internet2.edu
Scott Cantor
> the User to the URL provided where he can select an IDP from the list of
> available IDPs. So the session initiator handler would be
> http://dvc7617.lexisnexis.com:25007/Shibboleth.sso/WAYF.
It's preferable to leave this as /Login rather than /WAYF so that something
outside your system can rely on the URL being common.
> <SessionInitiator type="Chaining" Location="/Login"
> relayState="cookie" isDefault="true">
In this example, it would be /Login, and NOT /WAYF.
> Since the session initiator is defined to redirect to the IDP selection
> page, it is trying to do the same when IDP is trying to access the
> http://dvc7617.lexisnexis.com:25007/Shibboleth.sso/WAYF URL. Is this
> correct?
Not if you have the above in the file. The Location there is /Login, not
/WAYF.
> So, the IDP should be configured such a way that it should not access the
> session initiator handle because that will redirect back to the WAYF URL
> (IDP selection page). Is this correct?
Well, yes, but the IdP isn't configured to talk to anything, it's given the
URL to use when the request comes in, in the shire parameter.
> In that case what is the URL/handler that IDP is supposed to return the
> response?
Whatever the ACS location the SP wants the response returned to.
> And from there how does InProcess to OutOfProcess communication
> happens? Do I need to configure anything explicitly to tell InProcess to
> access particular location at OutOfProcess?
If you mean the SP's internal stuff, that has nothing to do with any of
this.
> You mentioned that the URL above is not formed correctly, and it didn't
come
> from the SP because there is no such ACS handler defined. I dint
understand
> this statement completely. Could you tell me which part of the URL is not
> correct as per you? I am not sure but I think this URL is formed at the
IDP
> side
The shire parameter is the ACS to use, and it's wrong in your example. It's
not formed by the IdP, it's given to the IdP in the request to it. Whatever
generated that request is broken.
-- Scott
Achugatla, Vijay K. (LNG-CON)
Scott,
Sorry for the confusion.. it is in fact /Login and not /WAYF. Now I think I understood the purpose of all the configurations that we discussed.
I am rewriting the same statement just to make sure that I understood the flow correctly. The URL https://cpc1764:25747/shibboleth-idp2/SSO?target=http://dvc7617.lexisnexis.com:25007&shire=http://dvc7617.lexisnexis.com:25007/Shibboleth.sso &providerId=https://sdauth.sciencedirect.com/ is sent to IDP in a request to it and it is not formed correctly in my case.
Below is the piece of code that is from WAYFSessionInitiator.cpp. Is this the place where the URL is created?
// WAYF requires a target value.
if (target.empty())
target = "default";
char timebuf[16];
sprintf(timebuf,"%lu",time(NULL));
const URLEncoder* urlenc = XMLToolingConfig::getConfig().getURLEncoder();
string req=string(m_url) + (strchr(m_url,'?') ? '&' : '?') + "shire=" + urlenc->encode(ACSloc.c_str()) +
"&time=" + timebuf + "&target=" + urlenc->encode(target.c_str()) +
"&providerId=" + urlenc->encode(app.getString("entityID").second);
If this URL is not formed by SP and IDP then it is formed by my application. I am asking this to make sure that I analyze the URL creation at the right place.
In IDP (1.3) metadata file I have an entry as given below
<AssertionConsumerService Binding="urn:oasis:names:tc:SAML:1.0:profiles:browser-post" Location="http://dvc7617.lexisnexis.com:25007/Shibboleth.sso" index="1"/>
Do you think I need to change the location? If yes what location should I give? I mean do I need to give any handler location?
Thanks,
Vijay
-----Original Message-----
From: Scott Cantor [mailto:cant...@osu.edu]
Sent: Tuesday, May 26, 2009 3:33 PM
To: shibbole...@internet2.edu
Subject: RE: [Shib-Users] Shibboleth handler invoked at an unconfigured
location
> As per the session initiator I defined (as given below), it will redirect
Scott Cantor
> the place where the URL is created?
If it came from the SP.
> If this URL is not formed by SP and IDP then it is formed by my
application.
> I am asking this to make sure that I analyze the URL creation at the right
> place.
I can't tell you what your application is or isn't doing, let alone what a
WAYF that you control (apparently) is or isn't doing.
> In IDP (1.3) metadata file I have an entry as given below
> <AssertionConsumerService
> Binding="urn:oasis:names:tc:SAML:1.0:profiles:browser-post"
> Location="http://dvc7617.lexisnexis.com:25007/Shibboleth.sso" index="1"/>
>
> Do you think I need to change the location? If yes what location should I
> give? I mean do I need to give any handler location?
Yes, you have to change it. Use the ACS handlers the SP includes by default.
The SAML 1 POST ACS is at /Shibboleth.sso/SAML/POST.
That doesn't explain what's generating that broken request, and it's not the
SP doing it unless you changed the configuration so profoundly that it's
causing a bug somewhere.
-- Scott
Achugatla, Vijay K. (LNG-CON)
Scott,
I think the URL is created at SP side because I could see the code related to this in both SP 1.3 (shib-handlers.cpp) and SP2.1. At the same time I also see the there is a piece of code in my application that is doing something with this URL. I’ll analyze my app to see what it is dong and correct if it is mishandling anything.
About ACS handler… I think I need to use the ACS handler based on the corresponding defaultACSIndex value for that session initiator. For example for Session Initiator type="WAYF" the defaultACSIndex="5". So I need to use the ACS with index 5 which is <md:AssertionConsumerService Location="/SAML/POST" index="5" Binding="urn:oasis:names:tc:SAML:1.0:profiles:browser-post"/>
Is that correct?
If I am using multiple Session Initiators then do I need to have an entry for each on in the IDP metadata? For example I have a SessionInitiator of type Chaining and in that I have defined 3 session initiators as below. Since their ACS index is different what should I give in IDP metadata? Do I need to give both index 1 and index 5 ACS handlers?
<SessionInitiator type="Chaining" Location="/Login" relayState="cookie" isDefault="true">
<SessionInitiator type="SAML2" defaultACSIndex="1" acsByIndex="false" template="bindingTemplate.html"/>
<SessionInitiator type="Shib1" defaultACSIndex="5"/>
<SessionInitiator type="WAYF" defaultACSIndex="5" URL="http://dvc7632.lexisnexis.com:25929/science/externallogin"/>
</SessionInitiator>
Thanks,
Vijay
-----Original Message-----
From: Scott Cantor [mailto:cant...@osu.edu]
Sent: Tuesday, May 26, 2009 4:29 PM
To: shibbole...@internet2.edu
Subject: RE: [Shib-Users] Shibboleth handler invoked at an unconfigured
location
> Below is the piece of code that is from WAYFSessionInitiator.cpp. Is this
Scott Cantor
> to this in both SP 1.3 (shib-handlers.cpp) and SP2.1. At the same time I
> also see the there is a piece of code in my application that is doing
> something with this URL. I'll analyze my app to see what it is dong and
> correct if it is mishandling anything.
There's no point guessing. If you hit the /Login URL, what does the redirect
look like? Not at the IdP but immediately after.
> About ACS handler. I think I need to use the ACS handler based on the
> corresponding defaultACSIndex value for that session initiator. For
> example for Session Initiator type="WAYF" the defaultACSIndex="5". So I
> need to use the ACS with index 5 which is <md:AssertionConsumerService
> Location="/SAML/POST" index="5"
> Binding="urn:oasis:names:tc:SAML:1.0:profiles:browser-post"/>
>
> Is that correct?
Well, yes, but you don't do anything here. The metadata MUST reflect ALL
possible ACS locations. Which one gets used is up to the SP.
> If I am using multiple Session Initiators then do I need to have an entry
> for each on in the IDP metadata?
There are no references to SessionInitiators in the metadata, with an
exception I'm not going to go into here because it's just beside the point.
> For example I have a SessionInitiator of
> type Chaining and in that I have defined 3 session initiators as below.
> Since their ACS index is different what should I give in IDP metadata? Do
I
> need to give both index 1 and index 5 ACS handlers?
The ACS locations in the metadata have nothing to do with the
SessionInitiators. You MUST enumerate all ACS locations defined in the SP
configuration, period. If you want to know what the metadata should probably
be for a particular host, just use the generator at /Shibboleth.sso/Metadata
and eyeball it.
-- Scott
Achugatla, Vijay K. (LNG-CON)
Scott,
I do not see any other URL other than this.
This is the same URL which you said is broken. I am analyzing the URL creation at my end. Is any standard URL format or any example URL which I can refer to to see what is the issue with my URL?
Below are the HTTP header traces that I captured
----------------------------------------------------------
GET /science?_ob=FederationURL&_method=validate&_type=f&_instId=635&fedId=17&_acct=C000071521&_version=1&_userid=7217986&md5=ec118a0ab590c41c07a92fa779f8ae11 HTTP/1.1
Host: dvc7632:25929
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.10) Gecko/2009042316 Firefox/3.0.10
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Referer: http://dvc7632:25929/science
Cookie: EUID=8e719d92-3e6b-11de-9709-00000ac4641e; FEDERATION_COOKIE=9a99329b4bcd999525091a961c85b0d2291b9a42b5233ca93592c896a6621f3e19e8adc2459f9ffc650f2d05fa7d936821616fadbdc6222bfd3d29b2cadb8e5141873b8ff0e9ee86; MIAMISESSION=8d8bf3b2-4a3e-11de-a8d4-00000ac4641e:3420827139; BROWSER_SUPPORTS_COOKIES=1; MIAMIAUTH=ea87f035f1382c1056b2a3922cc1c9987ff7f0fb325be2509c1c10b07a60ace5b48089822afbca295b5209d83516f26daf0fc7dba108186c18169003c626688fb40befcbd53547063703f50455c73bca5a2f2308fdb2a0b3f8521e6aa0196e90e8d63fdcffb933d473242d8f74821ac1d8dd1d4ea2135b1d970f5f3754c80b9d8a45b3fb9b1faeddcd26d6d3cce969d28432a6b41a5ea87bb0193535be633449f59463a9bf9d82290b4deb540d1808922526a145f178b65b441a5a05e2490dc9f90b2a66e8c9fc94462f8f0cb736bb88b0f5e40ec0dfb39ae07f3d086de07c5b; TARGET_URL=a836c56c167af2bfe996b0be497d5e1168d4d3d9550f3b67001bd10bf6d3eb96; RETURN_URL=
HTTP/1.x 301 Moved Permanently
Set-Cookie: MIAMISESSION=8d8bf3b2-4a3e-11de-a8d4-00000ac4641e:3420827171; path=/; HttpOnly;
Set-Cookie: FEDERATION_COOKIE=9a99329b4bcd999525091a961c85b0d2291b9a42b5233ca93592c896a6621f3e19e8adc2459f9ffc650f2d05fa7d936821616fadbdc6222bfd3d29b2cadb8e5141873b8ff0e9ee86; expires=Mon, 21 May 2029 21:46:11 GMT; HttpOnly;
Content-Type: text/html
Expires: Tue, 01 Jan 1980 04:00:00 GMT
----------------------------------------------------------
GET /shibboleth-idp2/SSO?target=http%3A%2F%2Fdvc7617.lexisnexis.com%3A25007&shire=http%3A%2F%2Fdvc7617.lexisnexis.com%3A25007%2FShibboleth.sso&providerId=https%3A%2F%2Fsdauth.sciencedirect.com%2F HTTP/1.1
Host: cpc1764:25747
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.10) Gecko/2009042316 Firefox/3.0.10
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Referer: http://dvc7632:25929/science
Cookie: JSESSIONID=20E27239C1DFD2745E042E0835C047A3
HTTP/1.x 401 Authorization Required
Date: Tue, 26 May 2009 21:46:11 GMT
Server: Apache/2.0.61 (Unix) mod_ssl/2.0.61 OpenSSL/0.9.8g mod_jk/1.2.25
WWW-Authenticate: Basic realm="Elsevier Dayton Information Technology (EDIT) IdP #2"
Content-Length: 519
Keep-Alive: timeout=15, max=100
Connection: Keep-Alive
Content-Type: text/html; charset=iso-8859-1
-----Original Message-----
From: Scott Cantor [mailto:cant...@osu.edu]
Sent: Tuesday, May 26, 2009 5:35 PM
To: shibbole...@internet2.edu
Subject: RE: [Shib-Users] Shibboleth handler invoked at an unconfigured
location
Achugatla, Vijay K. (LNG-CON) wrote on 2009-05-26:
Scott Cantor
> creation at my end. Is any standard URL format or any example URL which I
> can refer to to see what is the issue with my URL?
I have no idea how you could get the SP to generate that, but there's a bug
if it is. The shire value MUST be derived from an ACS location configured in
the SP. I see no obvious way to get the SP to derive an ACS location that's
equal to the handlerURL base value, because the Location attributes in the
ACS elements should always have something in them.
There is nothing at /Shibboleth.sso. It's a signaling prefix, nothing more.
The normal value is going to end with /Shibboleth.sso/SAML/POST or something
similar.
-- Scott
Bernd Oberknapp
According to this trace the URL is created by the application at
http://dvc7632:25929/science (a ScienceDirect site selection page or
something similar?) and not the SP SessionInitiator which doesn't
seem to be used at all.
Best regards,
Bernd
-- --------------------------------------------------------------------- --
Dipl.-Math. Bernd Oberknapp Universitaetsbibliothek Freiburg
Tel: +49-761 / 203-3852 Rempartstrasse 10-16 | Postfach 1629
Fax: +49-761 / 203-3987 79098 Freiburg | 79016 Freiburg
Scott Cantor
So, none of your traces show a request to the SP's SessionInitiator. Until I
see one showing that result in which the GET is clearly to the SP, I
conclude from your posted configuration and reviewing the code that you're
wrong about where the URL is coming from. Something else is in the middle
and is corrupting things.
Anything my code does is derived by mapping the defaultACSIndex to an ACS in
the Sessions element and building the URL from the Location of that ACS.
That isn't what your "example" is doing, ergo it's not the SP doing it.
-- Scott
Achugatla, Vijay K. (LNG-CON)
Scott,
I agree that my application might be doing something in the middle. But whatever it is doing its working of SP1.3. It might require some changes to make it compatible with SP2.1.
I’ll analyze that and change it accordingly.
N’ways thanks for your help on this issue
Thanks,
Vijay
-----Original Message-----
From: Scott Cantor [mailto:cant...@osu.edu]
Sent: Tuesday, May 26, 2009 7:25 PM
To: shibbole...@internet2.edu
Subject: RE: [Shib-Users] Shibboleth handler invoked at an unconfigured
location
> Below are the HTTP header traces that I captured
Scott Cantor
> whatever it is doing its working of SP1.3. It might require some changes
to
> make it compatible with SP2.1.
If it were doing the same thing it's doing now, it would break the old SP as
well, so it's just broken in a coincidentally working way, probably because
it has something hard-coded that shouldn't be.
> I'll analyze that and change it accordingly.
What you need to do for your own purposes is upgrade it to be compliant with
the SAML discovery service spec that Shibboleth supports. Otherwise you'll
end up orphaned on SAML 1.1 anyway.
-- Scott
Achugatla, Vijay K. (LNG-CON)
Scott,
I have corrected the broken URL and that issue is resolved. Thanks for you suggestions in that regard.
However I am now stuck with another issue. From the logs I could see that the IDP is releasing the attributes and SP is receiving them but for some reason the authentication is failing
Below are the SAML response sent by IDP and the same received by SP. I have marked the attributes that were released by IDP
At IDP
2009-05-27 15:16:54,652 DEBUG [IdP] -219267735 - Dumping generated SAML Response:
<Response xmlns="urn:oasis:names:tc:SAML:1.0:protocol" xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion" xmlns:samlp="urn:oasis:names:tc:SAML:1.0:protocol" x
mlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" InResponseTo="_af7aba6cb66514764eca4c5dee9761ef" IssueInstan
t="2009-05-27T19:16:54.648Z" MajorVersion="1" MinorVersion="1" ResponseID="_7c4a92d2b9c101ebe6c7cbfd7a206236"><Status><StatusCode Value="samlp:Success"></Stat
usCode></Status><Assertion xmlns="urn:oasis:names:tc:SAML:1.0:assertion" AssertionID="_1615e4ec9513d8d3414ba6886193af99" IssueInstant="2009-05-27T19:16:54.648
Z" Issuer="https://elsevier.test.federation/test-IdP2" MajorVersion="1" MinorVersion="1"><Conditions NotBefore="2009-05-27T19:16:54.648Z" NotOnOrAfter="2009-0
5-27T19:46:54.648Z"><AudienceRestrictionCondition><Audience>https://sdauth.sciencedirect.com/</Audience><Audience>https://elsevier.test.federation</Audience><
/AudienceRestrictionCondition></Conditions><AttributeStatement><Subject><NameIdentifier Format="urn:mace:shibboleth:1.0:nameIdentifier" NameQualifier="https:/
/elsevier.test.federation/test-IdP2">_bbdf31c9db0dd09ff8d582bfdb028780</NameIdentifier></Subject><Attribute AttributeName="urn:mace:dir:attribute-def:eduPerso
nEntitlement" AttributeNamespace="urn:mace:shibboleth:1.0:attributeNamespace:uri"><AttributeValue>TestEntitlement</AttributeValue></Attribute><Attribute Attri
buteName="urn:mace:dir:attribute-def:eduPersonTargetedID" AttributeNamespace="urn:mace:shibboleth:1.0:attributeNamespace:uri"><AttributeValue>166073e3a5a95728
616f_idp2-cert</AttributeValue></Attribute></AttributeStatement></Assertion></Response>
At SP
15:16:54.657(05/27) DEBUG XMLTooling.SOAPClient : received XML:
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"><soap:Body><Response xmlns="urn:oasis:names:tc:SAML:1.0:protocol" InResponseTo="_af7aba6cb66514764eca4c5dee9761ef" IssueInstant="2009-05-27T19:16:54.648Z" MajorVersion="1" MinorVersion="1" ResponseID="_7c4a92d2b9c101ebe6c7cbfd7a206236" xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion" xmlns:samlp="urn:oasis:names:tc:SAML:1.0:protocol"><Status><StatusCode Value="samlp:Success"/></Status><Assertion xmlns="urn:oasis:names:tc:SAML:1.0:assertion" AssertionID="_1615e4ec9513d8d3414ba6886193af99" IssueInstant="2009-05-27T19:16:54.648Z" Issuer="https://elsevier.test.federation/test-IdP2" MajorVersion="1" MinorVersion="1"><Conditions NotBefore="2009-05-27T19:16:54.648Z" NotOnOrAfter="2009-05-27T19:46:54.648Z"><AudienceRestrictionCondition><Audience>https://sdauth.sciencedirect.com/</Audience><Audience>https://elsevier.test.federation</Audience></AudienceRestrictionCondition></Conditions><AttributeStatement><Subject><NameIdentifier Format="urn:mace:shibboleth:1.0:nameIdentifier" NameQualifier="https://elsevier.test.federation/test-IdP2">_bbdf31c9db0dd09ff8d582bfdb028780</NameIdentifier></Subject><Attribute AttributeName="urn:mace:dir:attribute-def:eduPersonEntitlement" AttributeNamespace="urn:mace:shibboleth:1.0:attributeNamespace:uri"><AttributeValue>TestEntitlement</AttributeValue></Attribute><Attribute AttributeName="urn:mace:dir:attribute-def:eduPersonTargetedID" AttributeNamespace="urn:mace:shibboleth:1.0:attributeNamespace:uri"><AttributeValue>166073e3a5a95728616f_idp2-cert</AttributeValue></Attribute></AttributeStatement></Assertion></Response></soap:Body></soap:Envelope>
I do not see any error messages in the log but looking at the below message from shibd.log I feel that there is something wrong with the handling attributes after SP receives the response from IDP
The message says it cached following attributes but it dint display any attribute. I think I dint cache any attribute. Is that correct?
15:16:54.661(05/27) INFO Shibboleth-TRANSACTION : Cached the following attributes with session (ID: _952875fe12c4dcbb8c1f4306dd70b44c) for (applicationId: default) {
15:16:54.661(05/27) INFO Shibboleth-TRANSACTION : }
Does it has anything to do with the AttributeExtractor and AttributeFilter? I am using the original attribute-map.xml and attribute-policy.xml files as it is. I dint change any thing in those files. Do I need to make any changes to them>
Please let me know if you need any more details to understand the issue
Thanks,
Vijay
-----Original Message-----
From: Scott Cantor [mailto:cant...@osu.edu]
Sent: Tuesday, May 26, 2009 8:51 PM
To: shibbole...@internet2.edu
Subject: RE: [Shib-Users] Shibboleth handler invoked at an unconfigured
location
Achugatla, Vijay K. (LNG-CON) wrote on 2009-05-26:
Scott Cantor
- use the logs, which will tell you exactly what the SP is doing
- refer to the wiki for any documentation you need on the extraction/mapping
process
If at that point you still have a question, start a new thread for an
unrelated issue.
-- Scott
Achugatla, Vijay K. (LNG-CON)
Scott,
Below is from the latest shibd.log file. It was able to decode the two attributes entitlement and targeted-id but it removed entitlement after decoding.
“ignoring unscoped AttributeValue” does entitlement attribute fall under unscoped?
17:41:10.598(05/27) DEBUG OpenSAML.SecurityPolicyRule.MessageFlow : evaluating message flow policy (replay checking on, expiration 60)
17:41:10.598(05/27) DEBUG OpenSAML.SecurityPolicyRule.MessageFlow : evaluating message flow policy (replay checking on, expiration 60)
17:41:10.598(05/27) DEBUG XMLTooling.StorageService : inserted record (_3829fe9ab972834a84a29c045c69b0fb) in context (MessageFlow)
17:41:10.598(05/27) DEBUG OpenSAML.SecurityPolicyRule.MessageFlow : evaluating message flow policy (replay checking on, expiration 60)
17:41:10.598(05/27) DEBUG XMLTooling.StorageService : inserted record (_8cd5810c0e29161f51352bb952c1f2dd) in context (MessageFlow)
17:41:10.598(05/27) DEBUG Shibboleth.AttributeDecoder.String : decoding SimpleAttribute (entitlement) from SAML 1 Attribute (urn:mace:dir:attribute-def:eduPersonEntitlement) with 1 value(s)
17:41:10.598(05/27) DEBUG Shibboleth.AttributeDecoder.Scoped : decoding ScopedAttribute (targeted-id) from SAML 1 Attribute (urn:mace:dir:attribute-def:eduPersonTargetedID) with 1 value(s)
17:41:10.598(05/27) WARN Shibboleth.AttributeDecoder.Scoped : ignoring unscoped AttributeValue
17:41:10.598(05/27) DEBUG Shibboleth.AttributeFilter : filtering 1 attribute(s) from (https://elsevier.test.federation/test-IdP2)
17:41:10.598(05/27) DEBUG Shibboleth.AttributeFilter : applying filtering rule(s) for attribute (entitlement) from (https://elsevier.test.federation/test-IdP2)
17:41:10.598(05/27) WARN Shibboleth.AttributeFilter : removed value at position (0) of attribute (entitlement) from (https://elsevier.test.federation/test-IdP2)
17:41:10.598(05/27) WARN Shibboleth.AttributeFilter : no values left, removing attribute (entitlement) from (https://elsevier.test.federation/test-IdP2)
17:41:10.598(05/27) DEBUG Shibboleth.SessionCache : creating new session
17:41:10.599(05/27) DEBUG XMLTooling.XMLObject : starting to marshal saml:NameID
17:41:10.599(05/27) DEBUG XMLTooling.XMLObject : creating root element to marshall
17:41:10.599(05/27) DEBUG XMLTooling.XMLObject : marshalling namespace attributes for XMLObject
17:41:10.599(05/27) DEBUG XMLTooling.XMLObject : marshalling text and child elements for XMLObject
17:41:10.599(05/27) DEBUG XMLTooling.XMLObject : caching DOM for XMLObject (document is bound)
17:41:10.599(05/27) DEBUG Shibboleth.SessionCache : storing new session...
17:41:10.599(05/27) DEBUG XMLTooling.StorageService : inserted record (session) in context (_b28bb021cd7ad93ed648aa27430c1434)
17:41:10.599(05/27) DEBUG XMLTooling.StorageService : inserted record (_6475bb374c49ddf7e22ca25411d432c4) in context (NameID)
17:41:10.599(05/27) DEBUG XMLTooling.XMLObject : starting to marshal {urn:oasis:names:tc:SAML:1.0:assertion}Assertion
17:41:10.599(05/27) DEBUG XMLTooling.XMLObject : XMLObject has a usable cached DOM, reusing it
17:41:10.599(05/27) DEBUG XMLTooling.XMLObject : releasing cached DOM representation for parent object with propagation set to true
17:41:10.599(05/27) DEBUG XMLTooling.XMLObject : releasing cached DOM representation for ({urn:oasis:names:tc:SAML:1.0:protocol}Response)
17:41:10.599(05/27) DEBUG XMLTooling.StorageService : inserted record (_4bf01e67394b877b34ef8dff457420b8) in context (_b28bb021cd7ad93ed648aa27430c1434)
17:41:10.599(05/27) DEBUG XMLTooling.XMLObject : starting to marshal {urn:oasis:names:tc:SAML:1.0:assertion}Assertion
17:41:10.599(05/27) DEBUG XMLTooling.XMLObject : XMLObject has a usable cached DOM, reusing it
17:41:10.599(05/27) DEBUG XMLTooling.StorageService : inserted record (_8cd5810c0e29161f51352bb952c1f2dd) in context (_b28bb021cd7ad93ed648aa27430c1434)
17:41:10.599(05/27) INFO Shibboleth.SessionCache : new session created: ID (_b28bb021cd7ad93ed648aa27430c1434) IdP (https://elsevier.test.federation/test-IdP2) Protocol(urn:oasis:names:tc:SAML:1.1:protocol) Address (138.12.194.207)
17:41:10.599(05/27) INFO Shibboleth-TRANSACTION : New session (ID: _b28bb021cd7ad93ed648aa27430c1434) with (applicationId: default) for principal from (IdP: https://elsevier.test.federation/test-IdP2) at (ClientAddress: 138.12.194.207) with (NameIdentifier: _6475bb374c49ddf7e22ca25411d432c4) using (Protocol: urn:oasis:names:tc:SAML:1.1:protocol) from (AssertionID: _4bf01e67394b877b34ef8dff457420b8)
17:41:10.599(05/27) INFO Shibboleth-TRANSACTION : Cached the following attributes with session (ID: _b28bb021cd7ad93ed648aa27430c1434) for (applicationId: default) {
17:41:10.599(05/27) INFO Shibboleth-TRANSACTION : }
I think I am not clear with the AttributeFilter. Is it like whatever attributes motioned in the attribute-policy.xml will be removed? Or other than whatever is mentioned in attribute-policy.xml will be removed?
Below re the entries from my attribute-policy.xml file. I want to have these attributes. So are these entries appropriate or do I need to remove them from the attribute-policy.xml file?
<afp:AttributeRule attributeID="entitlement">
<afp:PermitValueRuleReference ref="ScopingRules"/>
</afp:AttributeRule>
<afp:AttributeRule attributeID="targeted-id">
<afp:PermitValueRuleReference ref="ScopingRules"/>
</afp:AttributeRule>
You mentioned that “targetedID isn't using a valid syntax because there's no Scope attribute”. Do you mean that the syntax of TargetedID is not correct in the SAML response or in my config file?
Thanks,
Vijay
-----Original Message-----
From: Scott Cantor [mailto:cant...@osu.edu]
Sent: Wednesday, May 27, 2009 5:43 PM
To: Achugatla, Vijay K. (LNG-CON)
Subject: RE: [Shib-Users] Shibboleth handler invoked at an unconfigured
location
FWIW, nothing immediately obvious seems to be wrong with one of the
attributes, but the targetedID isn't using a valid syntax because there's no
Scope attribute.
Your statement about there being nothing in the logs is simply impossible.
If you sent it something and it didn't cache any attributes, there will be
log information about what it did and why.
-- Scott
Scott Cantor
> "ignoring unscoped AttributeValue" does entitlement attribute fall under
> unscoped?
Entitlements are not scoped attributes.
> 17:41:10.598(05/27) DEBUG Shibboleth.AttributeDecoder.Scoped : decoding
> ScopedAttribute (targeted-id) from SAML 1 Attribute
(urn:mace:dir:attribute-
> def:eduPersonTargetedID) with 1 value(s)
>
> 17:41:10.598(05/27) WARN Shibboleth.AttributeDecoder.Scoped : ignoring
> unscoped AttributeValue
That's clearly referring to the targeted-id in the previous log message. I
told you in the private email that the attribute was incorrect, it's missing
a Scope XML attribute.
(That's also a deprecated attribute name and syntax anyway. Please refer to
the I2MI attribute profile document for the proper handling of targeted-id
attributes in SAML 1 and 2.)
> 17:41:10.598(05/27) WARN Shibboleth.AttributeFilter : removed value at
> position (0) of attribute (entitlement) from
> (https://elsevier.test.federation/test-IdP2)
That one's on you. There are no entitlement filters by default, so you must
have created one. Why?
> I think I am not clear with the AttributeFilter. Is it like whatever
> attributes motioned in the attribute-policy.xml will be removed? Or other
> than whatever is mentioned in attribute-policy.xml will be removed?
It's whatever you tell it to do. You can put in rules that will reject
things or rules that will allow things.
> Below re the entries from my attribute-policy.xml file. I want to have
these
> attributes. So are these entries appropriate or do I need to remove them
> from the attribute-policy.xml file?
Why are you changing it? What are you trying to accomplish that you think
requires a change?
> <afp:AttributeRule attributeID="entitlement">
> <afp:PermitValueRuleReference ref="ScopingRules"/>
> </afp:AttributeRule>
This is wrong (and is causing the filter to fire). Entitlements are not
scoped attributes.
> You mentioned that "targetedID isn't using a valid syntax because there's
no
> Scope attribute". Do you mean that the syntax of TargetedID is not correct
> in the SAML response or in my config file?
The syntax in the response is wrong, and is deprecated to begin with.
-- Scott