[Shib-Users] ezproxy -- Inter-institutional access failure
Bresaw, Joshua
I have one particular SP that won’t work with my IDP. It uses ezproxy. This is the only log message I’ve got to go on.
2008-08-19 08:22:58 No NameIdentifier in assertion
When I attempt to authenticate to the SP, my logs do not get any errors. I never see an attempted attribute query for this SP.
In the web browser, I get this page from the SP:
https://SP_URL:9100/Shibboleth.shire
Inter-institutional access failure. Please contact your system administrator for assistance.
How do I determine which side is responsible?
Scott Cantor
Your resolver configuration was changed from the defaults such that you
broke the built-in behavior that just releases a transient ID. Just roll
back, and don't touch that stuff.
> How do I determine which side is responsible?
Both are. It's a bug in EZProxy that it needs a NameID, but it was written a
long, long time ago, and only works in a constrained way. It's not fully
SAML compatible.
The only fix is on your side, you have to configure an attribute with a
legal NameIdentifier encoder. That's done for you, so you changed something
you didn't need to.
-- Scott
Roy, Nicholas S
>2008-08-19 08:22:58 No NameIdentifier in assertion
Joshua, it appears your SP may be missing an entityID. Try to turn logging up a notch or two and see what that yields.
Nick
------------
Nicholas Roy
System Programmer
The University of Iowa / ITS - Systems and Platforms / Directory and Authentication
100 Lindquist Center (South)
(319) 335 5510
------------
Chris G. Sellers
using or connecting to that could be helpful in where to debug.
Thank you and good luck
Sellers
++++++++++++++++++++++++++++++++++++++
Chris G. Sellers | Internet Engineer | NITLE
734.661.2318 | chris....@nitle.org
Jabber: csel...@nitle.org | AIM: imthewherd
Bresaw, Joshua
The only fix is on your side, you have to configure an attribute with a
legal NameIdentifier encoder. That's done for you, so you changed something
you didn't need to.
-- Scott
That makes sense but I think that I left all the default stuff intact; I compared my existing resolver.xml to the original resolver.xml and I have all the transient ID stuff including attribute defs, encoders, and principal connectors at the bottom.
My resolver has this:
<resolver:AttributeDefinition id="transientId" xsi:type="TransientId" xmlns="urn:mace:shibboleth:2.0:resolver:ad">
<resolver:AttributeEncoder xsi:type="SAML1StringNameIdentifier" xmlns="urn:mace:shibboleth:2.0:attribute:encoder"
nameFormat="urn:mace:shibboleth:1.0:nameIdentifier" />
<resolver:AttributeEncoder xsi:type="SAML2StringNameID" xmlns="urn:mace:shibboleth:2.0:attribute:encoder"
nameFormat="urn:oasis:names:tc:SAML:2.0:nameid-format:transient" />
</resolver:AttributeDefinition>
My filter has this:
<AttributeFilterPolicy id="releaseTransientIdToAnyone">
<PolicyRequirementRule xsi:type="basic:ANY" />
<AttributeRule attributeID="transientId">
<PermitValueRule xsi:type="basic:ANY" />
</AttributeRule>
</AttributeFilterPolicy>
That's all I should need right? My IDP is 2.0, the SP I'm working with is 1.x (1.3 I think). Someone mentioned that the SP may be missing an entityID. I checked my metadata and its in there. I'll be glad to gather debug logs but not sure what I'd be looking for.
Scott Cantor
> compared my existing resolver.xml to the original resolver.xml and I have
> all the transient ID stuff including attribute defs, encoders, and
principal
> connectors at the bottom.
Ok, it's outside my knowledge then, I don't run 2.0 yet. I just have to
assume that's the error. You should verify with logging that the assertion
being issued actually doesn't have a NameIdentifier in the subject, I guess.
If it does, then something else is wrong, but since EZproxy isn't
Shibboleth, this isn't our software to debug or support when it comes to
that end of things.
> That's all I should need right? My IDP is 2.0, the SP I'm working with is
> 1.x (1.3 I think).
No, it's not. It's not Shibboleth at all.
-- Scott
Bresaw, Joshua
10:52:32.500 DEBUG [edu.internet2.middleware.shibboleth.common.attribute.filtering.provider.ShibbolethAttributeFilteringEngine:105] - Filtered attributes for principal jbresaw1216. The following attributes remain: [eduPersonScopedAffiliation, transientId, eduPersonPrincipalName]
10:52:32.519 DEBUG [edu.internet2.middleware.shibboleth.idp.profile.saml1.AbstractSAML1ProfileHandler:356] - Building assertion NameIdentifier to relying party https://proxy.ohiolink.edu/shibboleth for principal jbresaw1216
10:52:32.520 DEBUG [edu.internet2.middleware.shibboleth.idp.profile.saml1.AbstractSAML1ProfileHandler:361] - SP-supported name formats: [urn:mace:shibboleth:1.0:nameIdentifier]
10:52:32.521 DEBUG [edu.internet2.middleware.shibboleth.idp.profile.saml1.AbstractSAML1ProfileHandler:381] - Using attribute transientId supporting name format urn:mace:shibboleth:1.0:nameIdentifier to create the NameIdentifier
10:52:32.538 DEBUG [edu.internet2.middleware.shibboleth.idp.profile.saml1.AbstractSAML1ProfileHandler:571] - Determining if SAML assertion to relying party https://proxy.ohiolink.edu/shibboleth should be signed
10:52:32.539 DEBUG [edu.internet2.middleware.shibboleth.idp.profile.saml1.AbstractSAML1ProfileHandler:597] - Entity metadata for relying party https://proxy.ohiolink.edu/shibboleth indicates to sign assertions: false
10:52:32.545 DEBUG [edu.internet2.middleware.shibboleth.idp.profile.AbstractSAMLProfileHandler:526] - Encoding response to SAML request null from relying party https://proxy.ohiolink.edu/shibboleth
> Ok, it's outside my knowledge then, I don't run 2.0 yet. I just have to
> assume that's the error. You should verify with logging that the assertion
> being issued actually doesn't have a NameIdentifier in the subject, I guess.
> If it does, then something else is wrong, but since EZproxy isn't
> Shibboleth, this isn't our software to debug or support when it comes to
> that end of things.
I understand that. I just wanted to make sure I was doing everything I could on the shibboleth side of things to make this transaction work. Thanks for the input. So does this put my end of things (the shibboleth side of things) in the clear?
Scott Cantor
> according to these log entries?
You're right to say it probably means that, but why guess? Look at the XML.
-- Scott
Bresaw, Joshua
Tom Scavo
> Sorry, but I'm not quite sure what you mean. Look at my XML config files? Capture some traffic and look for XML?
I think Scott was suggesting you look at the SAML assertion itself and
see if it contains a <NameID> or <NameIdentifier> element. Is the
SAML assertion dumped in the log?
HTH,
Tom
Bresaw, Joshua
<saml:NameIdentifier Format="urn:mace:shibboleth:1.0:nameIdentifier">_cd8aa531b56eacb28713b7c2d0b5ac55</saml:NameIdentifier>
Is this string of characters inside the element my encoded transientID? I think my end is working. Have I done all I can do from the shib side of things. Can I point the finger at EZproxy now:)?
Tom Scavo
> I see. I found this at TRACE level inside the SAML assertion.
>
> <saml:NameIdentifier Format="urn:mace:shibboleth:1.0:nameIdentifier">_cd8aa531b56eacb28713b7c2d0b5ac55</saml:NameIdentifier>
>
> Is this string of characters inside the element my encoded transientID?
It's the value of the NameIdentifier element, yes.
> I think my end is working. Have I done all I can do from the shib side of things. Can I point the finger at EZproxy now:)?
Well, maybe EZproxy doesn't support the proprietary
urn:mace:shibboleth:1.0:nameIdentifier Format, but I'd be surprised if
that were the cause since we would have heard about this before, no
doubt.
Tom
Scott Cantor
> think my end is working. Have I done all I can do from the shib side of
> things. Can I point the finger at EZproxy now:)?
Well, you can point the finger, but EZProxy is based on an attempt at
compatibility with a version of Shibboleth that predates any finalization of
the specs, and isn't even supported by us anymore.
We don't promise compatibility with that version ourselves, so...it's not
that surprising to me. I was hoping it would work, but I don't know if
anybody has actually tried it yet, you may be the first.
I really wish EZProxy just ran inside a web server like normal software and
let us use the standard SP with it. I'm going to be stuck the same as you if
we can't get this to work.
-- Scott
Bresaw, Joshua
Scott Cantor
> completing a shib transaction with it. Anyone who might have been
> apprehensive about upgrading their IDP b/c of this thread can now feel
> better about it.
Actually, it's still a major concern to me if my library has to upgrade.
That's not real likely. I've heard from the UK that they haven't gotten
reports of problems getting to 2.0 to work with the older EZProxy, so I'd
like to hear some confirmation of that, or an explanation for why this
didn't work for you.
-- Scott
Joana M. F. Trindade
Actually, it's still a major concern to me if my library has to upgrade.That's not real likely. I've heard from the UK that they haven't gotten
reports of problems getting to 2.0 to work with the older EZProxy, so I'd
like to hear some confirmation of that, or an explanation for why this
didn't work for you.
Excuse me for jumping into this thread, but it seems that support for Shib 2.0 was
introduced in EZProxy 5.1a, and is not/will not be available in previous versions.
HTH,
Joana
--
Joana M. F. da Trindade
Email: jmftr...@inf.ufrgs.br
Personal Homepage: http://joanatrindade.wikidot.com
LinkedIn: http://www.linkedin.com/in/joanatrindade
Scott Cantor
> 2.0 was introduced in EZProxy 5.1a, and is not/will not be available in
> previous versions.
I'm talking about the SAML 1.1 support. If it works with SAML 1.1 (and it
does, Shibboleth 1.3 works with it), I'm asking if (and if so, why) it
doesn't support it using Shibboleth 2.0.
It's a transitive issue. If 2.0 interops with 1.3 and 1.3 interops with
EZProxy < 5.1a, why doesn't 2.0 interop with it? I think it does, but
apparently not in every case, so I want to know what those cases are.
-- Scott
E. Stuart Hicks
Hash: SHA1
I'm not sure if this changes things or not but EZProxy prior to 5.1a is
designed for Shib 1.2 support. If IdP 2.0 broke 1.2-support then
EZProxy would go with it.
Stu
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAki3Z7UACgkQqmBbivzHElJWEwCfYE6SEIj24SxTET3/b5fEsQqv
O/MAn2TlFqcLRTfT6nP1YpkpVoOkP2js
=JUcC
-----END PGP SIGNATURE-----
Scott Cantor
> designed for Shib 1.2 support. If IdP 2.0 broke 1.2-support then
> EZProxy would go with it.
Yes, but it didn't explicitly break anything, it just doesn't support
various XML hacks that shouldn't have been required by EZProxy.
-- Scott
Chris Zagar
going on.
When I designed the Shibboleth 1.2 support for EZproxy, it was the first
time I used libxml and the first time I dealt with SAML. Although it
works, there are places where I simply didn't fully understand the spec,
and the name identifier handling is one of these areas.
When Shibboleth 2.0 went production last spring, it was time for EZproxy
to support 2.0, but it was clear that the EZproxy 1.2 code had enough
shortcomings that it should not act as the base. The Shibboleth 1.3/2.0
support in EZproxy was a rebuild instead of a rework.
Technically, it would be possible to go back and rework the old 1.2
support to fix things like the name identifier issue, but there's really
no reason since that would still involve institutions needing to upgrade,
and if you're going to upgrade anyway, you might as well just move to the
newer support.
Chris
Steven_...@brown.edu
Chris -- thanks very much for the definitive info.
Can you tell us the EZP version number where you introduced the new
Shib support, and removed the older implemention?
Scott Cantor
> support to fix things like the name identifier issue, but there's really
> no reason since that would still involve institutions needing to upgrade,
> and if you're going to upgrade anyway, you might as well just move to the
> newer support.
Would you be able to identify what the issue is? That's what I'm trying to
figure out. The error message in question did not make sense given the XML
that was reported. There was a normal NameIdentifier in the assertion,
so...?
Or was the information incorrect? I just want to know the scope of the issue
so I can plan for it.
-- Scott
Chris Zagar
> support, and removed the older implemention?
EZproxy 5.1 added the new 1.3/2.0 support, but retains the existing 1.2
support as well.
An institution that already uses the 1.2 support and updates to 5.1
without making any other changes will still only have 1.2 support active,
exactly as it has always been. The 1.3/2.0 support is enabled separately.
It is possible to run just 1.2, just 1.3/2.0, or both concurrently,
allowing existing users to migrate between versions as best meets their
schedules.
Chris
Scott Cantor
> support as well.
Final questions...is the 2.0/1.3 support just SAML 1.1, or SAML 2.0 also
(even if limited)? Is attribute push supported, or just the old POST + query
approach?
Thx,
-- Scott
Chris Zagar
> (even if limited)? Is attribute push supported, or just the old POST + query
> approach?
SAML 2.0 support was added in this release, including attribute push
through POST. Artifact is now supported, but not POST-SimpleSign. There
is also support to use Discovery Service.
Chris
Scott Cantor
> through POST. Artifact is now supported, but not POST-SimpleSign. There
> is also support to use Discovery Service.
Thanks, I'll refer to the docs for anything else. ;-)
-- Scott