Idpv3.1.1- two instance Issue

[Sandeep urs]

Hi ,
I too experienced this behavior . From the logs its evident that IDP 3.1.1
is doing  lookup of shibboleth session id   and deserialise attributes  .

Hence I have few queries

How to prevent idp3.1.1 from caching attributes ?
Or can I change cookie name of shibboleth based on 'idp.domain' domains
port  dynamically?

Please suggest .....
On Oct 1, 2015 7:13 PM, "Cantor, Scott" <cantor.2 at osu.edu> wrote:

> On 10/1/15, 8:07 AM, "users on behalf of sarath upadrista" <
> users-bounces at shibboleth.net on behalf of upadrista.sarath at gmail.com>
> wrote:
> >
> >At Brower-1 Tab2 ,
> >When accessing Instance#2-(http://localhost:9999/app), IdP3.1.1  is
> signalling this request as already authentic and responding with
> >A) Destination="http://localhost:9999/ConsumerServiceURL/SSO" and
> >B) saml2:AttributeStatement containg
> "username=slp145,accountType=10,sessionId=_f1cd58432436b7ac788fb7356e8a1328"
> >Please note here AttributeStatement for At Brower-1 Tab2 is not expected
> behaviour
>
> Well, that's up to the resolver configuration. The data connector results
> from the first login are cached if you tell it to do so, and in general
> there is no reason why attributes will tend to be different based on the SP
> unless the definitions make them different.
>
> >Please suggest Whether  IdP 3.1.1 Behavior is  correct for the above said
> scenario
>
> The only person who could possibly answer that is you.
>
> -- Scott
>
> --
> To unsubscribe from this list send an email to
> users-unsubscribe at shibboleth.net
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20151002/275e9580/attachment.html>