Fwd: Re: IdP v1.3a, CoSign, and Mozilla/Firefox

[Bill Doster <Bill.Doster@xxxxxxxxx>]

As Phil suspected, *not* a cosign problem.

----- Forwarded message from max@xxxxxxx -----
    Date: Tue, 23 Aug 2005 15:05:22 -0400 (EDT)
    From: "Mark K. Miller" <max@xxxxxxx>
Reply-To: shibboleth-users@xxxxxxxxxxxxx
 Subject: Re: IdP v1.3a, CoSign, and Mozilla/Firefox
      To: shibboleth-users@xxxxxxxxxxxxx


Chad's guess is correct!

Somehow the important step of configuring the cryptohandle got left out of
setting up our new v1.3a IdP environment (yeah, we had done that in our
old v1.1 setup.)  Rats!

Well, cryptohandle is configured now and the Mozilla/Firefox browser types
are happy with our loadbalanced blades.

Thank you, Chad!

On Tue, 23 Aug 2005, Chad La Joie wrote:

> I can take a guess.
>
> Assuming you're using the normal, in-memory, name identifier mapper and not
> the cryptohandle.  I suspect the user was authenticating to one IdP, getting
> a handle and hitting the SP.  It then queried the OTHER IdP with the handle.
> The second IdP did not have the given handle in it's in-memory cache and so
> could not resolve the handle to the appropriate principal name (the user's
> ID).
>
> At this point to do load balancing with 1.3 you need to use something other
> than the in-memory name identifier mapper (use something like the
> cryptohandle or develop something like a database backed implementation).
> Also you will NOT be able to use Artifacts unless you develop your own
> artifact mapper that uses an external store.
>
> That said, I'm currently working on an IdP extension that uses in-memory
> name identifier and artifact mapping mechanisms but replicates state across
> IdP nodes, but it's not done yet and I'm currently working on other things.
> I hope to be able to come back to it in a week or so.
>
> I also need to take some time and write all this up on the Wiki.  :)
>
> Mark K. Miller wrote:
>>
>> Ok, ignore all "trouble shooting" previously mentioned for this thread.
>>
>> Our IdP environment actually runs on 2 blades behind an SLB service on a
>> Cisco IOS switch.  We've been using this setup all along since we
>> originally setup shib v1.1.
>>
>> Just to make trouble shooting this problem a little simpler, I took one of
>> the shib blades out of the Server Load Balancer rotation.
>>
>> Well, it all works now.  Even when I switched the SLB to only use the
>> 'other' blade; it still all works.
>>
>> ?!?!?!?!?!?!?!?
>>
>>
>> On Tue, 23 Aug 2005, Mark K. Miller wrote:
>>
>>> On Mon, 22 Aug 2005, Scott Cantor wrote:
>>>
>>>>> Other browsers (IE, Safari, Opera) seem to be fine.  It appears that
>>>>> with
>>>>> Mozilla and Firefox the REMOTE_USER environment variable doesn't always
>>>>> get set.  However, sometimes it seems to loop "a lot" and then set the
>>>>> REMOTE_USER environment variable.  Also, its worth noting that other
>>>>> CoSign protected applications will work with these same Mozilla and
>>>>> Firefox sessions.
>>>>
>>>>
>>>> When you're talking about REMOTE_USER, I take it you mean on the IdP? As
>>>> in,
>>>> the servlet is cosign-protected, and sometimes REMOTE_USER isn't being
>>>> set?
>>>
>>>
>>> Yup, that's what I mean.
>>>
>>>> I'm a little surprised that's even physically possible.
>>>
>>>
>>> Imagine our surprise.
>>>
>>>> A mod_shib-protected URL that had requireSession set, for example, can't
>>>> physically execute to completion unless a session is there (the Shib
>>>> equiv.
>>>> of REMOTE_USER).
>>>>
>>>> And, of course, looping should be an infinite problem.
>>>
>>>
>>> Of course.
>>>
>>>>                                                        Either you loop or
>>>> you don't.
>>>
>>>
>>> Yeah, that's what I've always thought too.
>>>
>>>>            The only exception I could think of would be some kind of
>>>> clock
>>>> skew where it was floating on the edge.
>>>
>>>
>>> I don't see how this would just be isolated to Mozilla/Firefox browsers,
>>> but not affect other browsers?
>>>
>>>>> Here's what we're seeing in our shib-error.log:
>>>>
>>>>
>>>> If I'm accurately describing this above, I don't think the shib log is
>>>> even
>>>> relevant.
>>>
>>>
>>> We didn't think it was relevant, either.  But we thought we should include
>>> something.  So, this time I'll include the log entries of the attributes
>>> trying to be released:
>>>
>>> First, the correct release from an IE session:
>>>
>>> 2005-08-23 10:24:47,462 DEBUG [IdP] 464830406                           -
>>> Attribute Query Handle recognized.
>>> 2005-08-23 10:24:47,462 INFO  [IdP] 464830406                           -
>>> Request is for principal (max).
>>>
>>> Now, when I do the same thing with Mozilla, I get:
>>>
>>> 2005-08-23 10:28:01,198 DEBUG [IdP] 714274627                           -
>>> Request from Shibboleth version: 1.2.1a
>>> 2005-08-23 10:28:01,198 DEBUG [IdP] 714274627                           -
>>> Name Identifier format: (urn:mace:shibboleth:1.0:nameIdentifier).
>>> 2005-08-23 10:28:01,198 DEBUG [IdP] 714274627                           -
>>> The Name Mapping Cache does not contain an entry for this Attribute Query
>>> Handle.
>>> 2005-08-23 10:28:01,198 ERROR [IdP] 714274627                           -
>>> Could not associate the request's subject with a principal:
>>> edu.internet2.middleware.shibboleth.common.InvalidNameIdentifierException:
>>> The Name Mapping Cache does not contain an entry for this Attribute Query
>>> Handle.
>>> 2005-08-23 10:28:01,198 ERROR [IdP] 714274627                           -
>>> Error while processing request: org.opensaml.SAMLException: The supplied
>>> Subject was unrecognized.
>>> 2005-08-23 10:28:01,199 DEBUG [IdP] 714274627                           -
>>> Dumping generated SAML Error 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"
>>> xmlns:xsd="http://www.w3.org/2001/XMLSchema";
>>> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
>>> InResponseTo="b0b40bd0d698e4e0d8fe8a0b67905de4"
>>> IssueInstant="2005-08-23T14:28:01.198Z" MajorVersion="1" MinorVersion="1"
>>> ResponseID="_ad1855cb1f6fd1bd310239af42821811"><Status><StatusCode
>>> Value="samlp:Requester"><StatusCode xmlns:code="urn:mace:shibboleth:1.0"
>>> Value="code:InvalidHandle"></StatusCode></StatusCode><StatusMessage>The
>>> supplied Subject was unrecognized.</StatusMessage></Status></Response>
>>> 2005-08-23 10:28:01,199 DEBUG [IdP] 714274627                           -
>>> Returning SAML Error Response.
>>>
>>>> That's not unusual if your handleTTL is short and the attributes expire
>>>> too
>>>> quickly, which is unfortunately more or less the default until 1.3. I
>>>> don't
>>>> see the connection with how the servlet is protected.
>>>
>>>
>>> Well, logically, I'm making the connection this way.  Changing the
>>> protection from CoSign to basic auth makes this strange behavior go away.
>>>
>
> --
> Chad La Joie             315Q St. Mary's Hall
> Project Sentinel         202.687.0124
>




----- End forwarded message -----