Idpv3.1.1- two instance Issue

[sarath upadrista]

Hi ,

We have typical scenario as described below observed in Idp 3.1.1

We want to run the *two instance of same application in two different tabs
of same browser*


   - let say instance#1(http://localhost:8888/app) & instance#2 (
   http://localhost:9999/app) running at port 8888 & 9999 respectively .
   - Instance#1 uses 'Tomcat1' and Instance#2 uses 'Tomcat2' .
   - We created our 'application' cookieset by appending  cookienames with
   respective port numbers.
                                                          --The purpose of
   creating  two cookiesets [one for each Application Instance] is because,We
   want  to treat 2 Instances as different We are using Idp3.1.1 and following
   were observed


*At Brower-1 Tab1 *
When accessing Instance#1-(http://localhost:8888/app) ,we were able to
authenticate using Idp3.1.1 and successfully landed to our application
*Note1: *
Our SAML Response contains
A) Destination="http://localhost:8888/ConsumerServiceURL/SSO" and
B) saml2:AttributeStatement containg "
username=slp145,accountType=10,sessionId=_f1cd58432436b7ac788fb7356e8a1328"


*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 *

Please find the log traces from idp-process.log file

--------------------------------------------------------------------------------------------------------------------idp-process.log----------------------------------------------------------------------------------------
2015-10-01 11:25:38,012 - DEBUG
[net.shibboleth.idp.saml.saml2.profile.impl.ProcessRequestedAuthnContext:148]
- Profile Action ProcessRequestedAuthnContext: RequestedPrincipalContext
created with operator exact and 1 custom principal(s)
2015-10-01 11:25:38,074 - DEBUG
[net.shibboleth.idp.authn.impl.PopulateAuthenticationContext:125] - Profile
Action PopulateAuthenticationContext: Installing custom
PrincipalEvalPredicateFactoryRegistry into AuthenticationContext
2015-10-01 11:25:38,074 - DEBUG
[net.shibboleth.idp.authn.impl.PopulateAuthenticationContext:158] - Profile
Action PopulateAuthenticationContext: Installed 1 authentication flows into
AuthenticationContext
2015-10-01 11:25:38,079 - DEBUG
[net.shibboleth.idp.session.impl.StorageBackedSessionManager:675] -
Performing primary lookup on session ID
d7050694ac05fd66e6cd8a428308af6c7461ede047ee4cc6285eaae377327c7e
2015-10-01 11:25:38,097 - DEBUG
[net.shibboleth.idp.session.impl.StorageBackedIdPSession:90] - Updating
expiration of master record for session
d7050694ac05fd66e6cd8a428308af6c7461ede047ee4cc6285eaae377327c7e to
2015-10-01T12:25:38.097Z
2015-10-01 11:25:38,098 - INFO
[net.shibboleth.idp.session.AbstractIdPSession:378] - Session
d7050694ac05fd66e6cd8a428308af6c7461ede047ee4cc6285eaae377327c7e not yet
locked to a IPV4 address, locking it to 127.0.0.1
2015-10-01 11:25:38,100 - DEBUG
[net.shibboleth.idp.session.impl.StorageBackedIdPSession:523] - Loading
AuthenticationResult for flow authn/External in session
d7050694ac05fd66e6cd8a428308af6c7461ede047ee4cc6285eaae377327c7e
2015-10-01 11:25:38,110 - DEBUG
[net.shibboleth.idp.session.impl.ExtractActiveAuthenticationResults:112] -
Profile Action ExtractActiveAuthenticationResults: authentication result
authn/External is active, copying from session
2015-10-01 11:25:38,125 - DEBUG
[net.shibboleth.idp.authn.impl.FilterFlowsByForcedAuthn:53] - Profile
Action FilterFlowsByForcedAuthn: Request does not have forced
authentication requirement, nothing to do
2015-10-01 11:25:38,127 - DEBUG
[net.shibboleth.idp.authn.impl.FilterFlowsByPassivity:53] - Profile Action
FilterFlowsByPassivity: Request does not have passive requirement, nothing
to do
2015-10-01 11:25:38,130 - DEBUG
[net.shibboleth.idp.authn.impl.FilterFlowsByNonBrowserSupport:53] - Profile
Action FilterFlowsByNonBrowserSupport: Request does not have non-browser
requirement, nothing to do
2015-10-01 11:25:38,133 - DEBUG
[net.shibboleth.idp.authn.impl.SelectAuthenticationFlow:341] - Profile
Action SelectAuthenticationFlow: Specific principals requested with 'exact'
operator:
[AuthnContextClassRefPrincipal{authnContextClassRef=urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport}]
2015-10-01 11:25:38,133 - DEBUG
[net.shibboleth.idp.authn.impl.SelectAuthenticationFlow:445] - Profile
Action SelectAuthenticationFlow: Checking for an inactive flow or active
result compatible with operator 'exact' and principal
'AuthnContextClassRefPrincipal{authnContextClassRef=urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport}'
2015-10-01 11:25:38,134 - DEBUG
[net.shibboleth.idp.authn.principal.PrincipalEvalPredicateFactoryRegistry:80]
- Registry located predicate factory of type
'net.shibboleth.idp.authn.principal.impl.ExactPrincipalEvalPredicateFactory'
for principal type 'class
net.shibboleth.idp.saml.authn.principal.AuthnContextClassRefPrincipal' and
operator 'exact'
2015-10-01 11:25:38,135 - DEBUG
[net.shibboleth.idp.authn.impl.SelectAuthenticationFlow:325] - Profile
Action SelectAuthenticationFlow: Reusing active result authn/External
2015-10-01 11:25:38,138 - DEBUG
[net.shibboleth.idp.authn.impl.FinalizeAuthentication:102] - Profile Action
FinalizeAuthentication: Canonical principal name established from session
as
'username=slp145,accountType=10,sessionId=_f1cd58432436b7ac788fb7356e8a1328'
2015-10-01 11:25:38,141 - DEBUG
[net.shibboleth.idp.session.impl.UpdateSessionWithAuthenticationResult:205]
- Profile Action UpdateSessionWithAuthenticationResult: Updating activity
time on reused AuthenticationResult for flow authn/External in existing
session d7050694ac05fd66e6cd8a428308af6c7461ede047ee4cc6285eaae377327c7e
2015-10-01 11:25:38,146 - DEBUG
[net.shibboleth.idp.attribute.resolver.impl.AttributeResolverImpl:182] -
Attribute Resolver 'ShibbolethAttributeResolver': Initiating attribute
resolution
--------------------------------------------------------------------------------------------------------------------idp-process.log----------------------------------------------------------------------------------------


Please suggest Whether  IdP 3.1.1 Behavior is  correct for the above said
scenario
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20151001/f9215ffe/attachment.html>