"ignoring Assertion without strongly matching NameID in Subject"

classic Classic list List threaded Threaded
20 messages Options
Reply | Threaded
Open this post in threaded view
|

"ignoring Assertion without strongly matching NameID in Subject"

Howes, Nick
Hello,

I'm testing a replacement 2.2 IdP for our currently running 2.1.2 IdP.
Testing with a 2.3.1 SP, it will successfully fetch attributes from the
live 2.1.2 IdP but it rejects the attribute response from the 2.2 IdP
with this log line:

2011-01-06 10:05:36 WARN Shibboleth.AttributeResolver.Query [1]:
ignoring Assertion without strongly matching NameID in Subject:
<saml2:NameID xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion"
Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient"
NameQualifier="https://idp.warwick.ac.uk/idp/shibboleth">_741c63fe539beab90b4d336fbf2a4f26</saml2:NameID>

A few other things have changed other than the IdP version, but is there
anything obvious I should look at? attribute-resolver.xml hasn't really
changed.

Any pointers appreciated.

Nick Howes
University of Warwick
Reply | Threaded
Open this post in threaded view
|

Re: "ignoring Assertion without strongly matching NameID in Subject"

lajoie
Administrator
The IdP has always had the behavior that is causing you problems.  Scott
submitted a feature request, which is marked against IdPv3, to address this:
https://bugs.internet2.edu/jira/browse/SIDPT-23

On 1/6/11 5:33 AM, Nick Howes wrote:

> Hello,
>
> I'm testing a replacement 2.2 IdP for our currently running 2.1.2 IdP.
> Testing with a 2.3.1 SP, it will successfully fetch attributes from the
> live 2.1.2 IdP but it rejects the attribute response from the 2.2 IdP
> with this log line:
>
> 2011-01-06 10:05:36 WARN Shibboleth.AttributeResolver.Query [1]:
> ignoring Assertion without strongly matching NameID in Subject:
> <saml2:NameID xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion"
> Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient"
> NameQualifier="https://idp.warwick.ac.uk/idp/shibboleth">_741c63fe539beab90b4d336fbf2a4f26</saml2:NameID>
>
>
> A few other things have changed other than the IdP version, but is there
> anything obvious I should look at? attribute-resolver.xml hasn't really
> changed.
>
> Any pointers appreciated.
>
> Nick Howes
> University of Warwick
>

--
Chad La Joie
http://itumi.biz
trusted identities, delivered
Reply | Threaded
Open this post in threaded view
|

Re: "ignoring Assertion without strongly matching NameID in Subject"

Howes, Nick
Okay. In that case I'm not sure how it was working at all against the
2.1.2 IdP. But if this is due to a change on the SP then presumably
there shouldn't be any problem for any existing SPs that we currently
talk to successfully.

Do you know if there's any workaround for the IdP configuration, or a
configuration option on the SP to disable this new check? I guess I
could try downgrading the test SP.

On 06/01/11 10:40, Chad La Joie wrote:

> The IdP has always had the behavior that is causing you problems.  
> Scott submitted a feature request, which is marked against IdPv3, to
> address this:
> https://bugs.internet2.edu/jira/browse/SIDPT-23
>
> On 1/6/11 5:33 AM, Nick Howes wrote:
>> Hello,
>>
>> I'm testing a replacement 2.2 IdP for our currently running 2.1.2 IdP.
>> Testing with a 2.3.1 SP, it will successfully fetch attributes from the
>> live 2.1.2 IdP but it rejects the attribute response from the 2.2 IdP
>> with this log line:
>>
>> 2011-01-06 10:05:36 WARN Shibboleth.AttributeResolver.Query [1]:
>> ignoring Assertion without strongly matching NameID in Subject:
>> <saml2:NameID xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion"
>> Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient"
>> NameQualifier="https://idp.warwick.ac.uk/idp/shibboleth">_741c63fe539beab90b4d336fbf2a4f26</saml2:NameID>
>>
>>
>>
>> A few other things have changed other than the IdP version, but is there
>> anything obvious I should look at? attribute-resolver.xml hasn't really
>> changed.
>>
>> Any pointers appreciated.
>>
>> Nick Howes
>> University of Warwick
>>
>

Reply | Threaded
Open this post in threaded view
|

Re: "ignoring Assertion without strongly matching NameID in Subject"

lajoie
Administrator
The easiest fix is to push attributes, that way the attribute query
never occurs.

On 1/6/11 7:07 AM, Nick Howes wrote:

> Okay. In that case I'm not sure how it was working at all against the
> 2.1.2 IdP. But if this is due to a change on the SP then presumably
> there shouldn't be any problem for any existing SPs that we currently
> talk to successfully.
>
> Do you know if there's any workaround for the IdP configuration, or a
> configuration option on the SP to disable this new check? I guess I
> could try downgrading the test SP.
>
> On 06/01/11 10:40, Chad La Joie wrote:
>> The IdP has always had the behavior that is causing you problems.
>> Scott submitted a feature request, which is marked against IdPv3, to
>> address this:
>> https://bugs.internet2.edu/jira/browse/SIDPT-23
>>
>> On 1/6/11 5:33 AM, Nick Howes wrote:
>>> Hello,
>>>
>>> I'm testing a replacement 2.2 IdP for our currently running 2.1.2 IdP.
>>> Testing with a 2.3.1 SP, it will successfully fetch attributes from the
>>> live 2.1.2 IdP but it rejects the attribute response from the 2.2 IdP
>>> with this log line:
>>>
>>> 2011-01-06 10:05:36 WARN Shibboleth.AttributeResolver.Query [1]:
>>> ignoring Assertion without strongly matching NameID in Subject:
>>> <saml2:NameID xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion"
>>> Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient"
>>> NameQualifier="https://idp.warwick.ac.uk/idp/shibboleth">_741c63fe539beab90b4d336fbf2a4f26</saml2:NameID>
>>>
>>>
>>>
>>> A few other things have changed other than the IdP version, but is there
>>> anything obvious I should look at? attribute-resolver.xml hasn't really
>>> changed.
>>>
>>> Any pointers appreciated.
>>>
>>> Nick Howes
>>> University of Warwick
>>>
>>
>
>

--
Chad La Joie
http://itumi.biz
trusted identities, delivered
Reply | Threaded
Open this post in threaded view
|

Re: "ignoring Assertion without strongly matching NameID in Subject"

Howes, Nick
I suppose that is a workaround :) Thanks.

On 06/01/11 12:10, Chad La Joie wrote:

> The easiest fix is to push attributes, that way the attribute query
> never occurs.
>
> On 1/6/11 7:07 AM, Nick Howes wrote:
>> Okay. In that case I'm not sure how it was working at all against the
>> 2.1.2 IdP. But if this is due to a change on the SP then presumably
>> there shouldn't be any problem for any existing SPs that we currently
>> talk to successfully.
>>
>> Do you know if there's any workaround for the IdP configuration, or a
>> configuration option on the SP to disable this new check? I guess I
>> could try downgrading the test SP.
>>
>> On 06/01/11 10:40, Chad La Joie wrote:
>>> The IdP has always had the behavior that is causing you problems.
>>> Scott submitted a feature request, which is marked against IdPv3, to
>>> address this:
>>> https://bugs.internet2.edu/jira/browse/SIDPT-23
>>>
>>> On 1/6/11 5:33 AM, Nick Howes wrote:
>>>> Hello,
>>>>
>>>> I'm testing a replacement 2.2 IdP for our currently running 2.1.2 IdP.
>>>> Testing with a 2.3.1 SP, it will successfully fetch attributes from
>>>> the
>>>> live 2.1.2 IdP but it rejects the attribute response from the 2.2 IdP

Reply | Threaded
Open this post in threaded view
|

Re: "ignoring Assertion without strongly matching NameID in Subject"

Howes, Nick

>> On 1/6/11 7:07 AM, Nick Howes wrote:
>>> Okay. In that case I'm not sure how it was working at all against the
>>> 2.1.2 IdP.

Turns out it was working through attribute push as per Chad's
suggestion, which explains the mystery.

>>>
>>> On 06/01/11 10:40, Chad La Joie wrote:
>>>> The IdP has always had the behavior that is causing you problems.
>>>> Scott submitted a feature request, which is marked against IdPv3, to
>>>> address this:
>>>> https://bugs.internet2.edu/jira/browse/SIDPT-23
>>>>
>>>> On 1/6/11 5:33 AM, Nick Howes wrote:
>>>>> Hello,
>>>>>
>>>>> I'm testing a replacement 2.2 IdP for our currently running 2.1.2
>>>>> IdP.
>>>>> Testing with a 2.3.1 SP, it will successfully fetch attributes
>>>>> from the
>>>>> live 2.1.2 IdP but it rejects the attribute response from the 2.2 IdP
>

Reply | Threaded
Open this post in threaded view
|

Re: "ignoring Assertion without strongly matching NameID in Subject"

lajoie
Administrator
In general there is no reason to not do attribute push with SAML 2.

Personally I think SAML 1 is fine as well but others disagree based on
concerns that the attributes are passing through the browser "in the
clear" (technically, they're slightly obfuscated by base64 encoding).
My view is that if the browser/host is compromised then attributes
passing through the browser is really the least of your worries since
the user just typed in their username/password right before that.

On 1/6/11 9:20 AM, Nick Howes wrote:

>
>>> On 1/6/11 7:07 AM, Nick Howes wrote:
>>>> Okay. In that case I'm not sure how it was working at all against the
>>>> 2.1.2 IdP.
>
> Turns out it was working through attribute push as per Chad's
> suggestion, which explains the mystery.
>
>>>>
>>>> On 06/01/11 10:40, Chad La Joie wrote:
>>>>> The IdP has always had the behavior that is causing you problems.
>>>>> Scott submitted a feature request, which is marked against IdPv3, to
>>>>> address this:
>>>>> https://bugs.internet2.edu/jira/browse/SIDPT-23
>>>>>
>>>>> On 1/6/11 5:33 AM, Nick Howes wrote:
>>>>>> Hello,
>>>>>>
>>>>>> I'm testing a replacement 2.2 IdP for our currently running 2.1.2
>>>>>> IdP.
>>>>>> Testing with a 2.3.1 SP, it will successfully fetch attributes
>>>>>> from the
>>>>>> live 2.1.2 IdP but it rejects the attribute response from the 2.2 IdP
>>
>
>

--
Chad La Joie
http://itumi.biz
trusted identities, delivered
Reply | Threaded
Open this post in threaded view
|

Passive login problem

William Fulmer
In reply to this post by Howes, Nick
I'm sure that I'm missing something obvious, but I've been banging my head against this for about a week now without finding a solution, so I'm hoping someone here can point me in the right direction.
 
I'm in the process of upgrading my IDP from 2.0.0 to 2.2.0.  I have merged my config into the config that comes with 2.2.0 when you do a fresh install.  All active authentication requests succeed, even for the SP (Google Apps for edu) for which passive authentication request fails.
 
The request coming into the IDP looks like this:
 
10.2.11.120 - - [04/Jan/2011:16:53:07 -0500] "GET /idp/profile/SAML2/Redirect/SSO?SAMLRequest=fVLJTsMwEL0j8Q%2BR781SgQRWE1RAiEosEQ0cuLnOkLrEM8HjtPD3uCnrASSfnp%2FfMp7JyattozU4NoS5yOJURICaaoNNLu6ri9GROCn29yasbNvJae%2BXeAcvPbCPwktkOVzkoncoSbFhicoCS6%2FlfHp9JcdxKjtHnjS1Ipqd5%2BK5Qd3ohVJGd2QQl6uayK5MhxqoXq2e9cIstAURPXzGGm9jzZh7mCF7hT5AaZaN0nAOqnEmDw9levwoovLD6dTgrsF%2FsRY7EsvLqipH5e28GgTWpgZ3E9i5aIiaFmJNdmtfKmazDrB3fUg3ZQbnQ74zQu4tuDm4tdFwf3eVi6X3Hcsk2Ww28bdKohLulAsNYiTnl8p2njCGuk%2BUZlEMU5ZDUfdjvP%2FXUJ85RPHtNEl%2BSBUfv7ctNTsvqTX6LZq2LW3OHCj%2F1eiCnFX%2Bb7cszgbE1KOngSp75A60eTJQiygpdq6%2F1yQszzs%3D&RelayState=https%3A%2F%2Fwww.google.com%2Fa%2Fspartan.northampton.edu%2FServiceLogin%3Fcontinue%3Dhttp%253A%252F%252Fpartnerpage.google.com%252Fspartan.northampton.edu%252Fdefault%252Fpostlogin%253Fpid%253Dspartan.northampton.edu%2526url%253Dhttp%253A%252F%252Fpartnerpage.google.com%252Fspartan.northampton.edu%26followup%3Dhttp%253A%252F%252Fpartnerpage.google.com%252Fspartan.northampton.edu%252Fdefault%252Fpostlogin%253Fpid%253Dspartan.northampton.edu%2526url%253Dhttp%253A%252F%252Fpartnerpage.google.com%252Fspartan.northampton.edu%26service%3Dig%26passive%3Dtrue%26cd%3DUS%26hl%3Den%26nui%3D1%26ltmpl%3Ddefault%26go%3Dtrue%26passive_sso%3Dtrue HTTP/1.1" 302 - "-" "Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; Trident/4.0; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.04506.30; MDDR; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729; InfoPath.2)
 
The SAML message is initialy decoded successfully to:
 
<?xml version="1.0" encoding="UTF-8"?><samlp:AuthnRequest xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" AssertionConsumerServiceURL="https://www.google.com/a/spartan.northampton.edu/acs" ID="jngndcbhadjciloadiomdgeacjhgfciacnbnlfih" IsPassive="true" IssueInstant="2011-01-06T13:56:12Z" ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" ProviderName="google.com" Version="2.0">
   <saml:Issuer xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">google.com</saml:Issuer>
   <samlp:NameIDPolicy AllowCreate="true" Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified"/>
</samlp:AuthnRequest>
 
Trace level logging on the old and new IDP's looks essentially the same up until after the IDP determines that there is no current authenticated session.  The logging on the new IDP after control is passed back to the the SAML2 Redirect SSo profile.  See below:
 
08:54:03.638 - DEBUG [edu.internet2.middleware.shibboleth.idp.authn.AuthenticationEngine:171] - Redirecting user to profile handler at https://shib.northampton.edu:443/idp/profile/SAML2/Redirect/SSO
08:54:03.642 - TRACE [edu.internet2.middleware.shibboleth.idp.session.IdPSessionFilter:105] - Attempting to retrieve IdP session cookie.
08:54:03.642 - INFO [Shibboleth-Access:73] - 20110106T135403Z|10.2.11.120|shib.northampton.edu:443|/profile/SAML2/Redirect/SSO|
08:54:03.642 - DEBUG [edu.internet2.middleware.shibboleth.idp.profile.IdPProfileHandlerManager:85] - shibboleth.HandlerManager: Looking up profile handler for request path: /SAML2/Redirect/SSO
08:54:03.642 - DEBUG [edu.internet2.middleware.shibboleth.idp.profile.IdPProfileHandlerManager:93] - shibboleth.HandlerManager: Located profile handler of the following type for the request path: edu.internet2.middleware.shibboleth.idp.profile.saml2.SSOProfileHandler
08:54:03.642 - DEBUG [edu.internet2.middleware.shibboleth.idp.util.HttpServletHelper:326] - Looking up LoginContext with key ff699ade-b3e7-4861-b338-d55a2c2a670d from StorageService parition: loginContexts
08:54:03.642 - DEBUG [edu.internet2.middleware.shibboleth.idp.util.HttpServletHelper:332] - Retrieved LoginContext with key ff699ade-b3e7-4861-b338-d55a2c2a670d from StorageService parition: loginContexts
08:54:03.642 - DEBUG [edu.internet2.middleware.shibboleth.idp.profile.saml2.SSOProfileHandler:159] - Incoming request contained a login context but principal was not authenticated, processing as first leg of request
08:54:03.643 - DEBUG [edu.internet2.middleware.shibboleth.idp.profile.saml2.SSOProfileHandler:304] - Decoding message with decoder binding 'urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect'
08:54:03.643 - DEBUG [org.opensaml.ws.message.decoder.BaseMessageDecoder:72] - Beginning to decode message from inbound transport of type: org.opensaml.ws.transport.http.HttpServletRequestAdapter
08:54:03.643 - DEBUG [org.opensaml.saml2.binding.decoding.HTTPRedirectDeflateDecoder:89] - Decoded RelayState: null
08:54:03.643 - WARN [edu.internet2.middleware.shibboleth.idp.profile.saml2.SSOProfileHandler:336] - Error decoding authentication request message
org.opensaml.ws.message.decoder.MessageDecodingException: No SAMLRequest or SAMLResponse query path parameter, invalid SAML 2 HTTP Redirect message
 at org.opensaml.saml2.binding.decoding.HTTPRedirectDeflateDecoder.doDecode(HTTPRedirectDeflateDecoder.java:97) ~[opensaml-2.4.0.jar:na]
 at org.opensaml.ws.message.decoder.BaseMessageDecoder.decode(BaseMessageDecoder.java:75) ~[openws-1.4.0.jar:na]
 at org.opensaml.saml2.binding.decoding.BaseSAML2MessageDecoder.decode(BaseSAML2MessageDecoder.java:69) ~[opensaml-2.4.0.jar:na]
 at edu.internet2.middleware.shibboleth.idp.profile.saml2.SSOProfileHandler.decodeRequest(SSOProfileHandler.java:324) [shibboleth-identityprovider-2.2.0.jar:na]
 at edu.internet2.middleware.shibboleth.idp.profile.saml2.SSOProfileHandler.performAuthentication(SSOProfileHandler.java:186) [shibboleth-identityprovider-2.2.0.jar:na]
 at edu.internet2.middleware.shibboleth.idp.profile.saml2.SSOProfileHandler.processRequest(SSOProfileHandler.java:160) [shibboleth-identityprovider-2.2.0.jar:na]
 at edu.internet2.middleware.shibboleth.idp.profile.saml2.SSOProfileHandler.processRequest(SSOProfileHandler.java:84) [shibboleth-identityprovider-2.2.0.jar:na]
 at edu.internet2.middleware.shibboleth.common.profile.ProfileRequestDispatcherServlet.service(ProfileRequestDispatcherServlet.java:83) [shibboleth-common-1.2.0.jar:na]
 at javax.servlet.http.HttpServlet.service(HttpServlet.java:717) [servlet-api.jar:na]
 at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) [catalina.jar:6.0.29]
 at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) [catalina.jar:6.0.29]
 at edu.internet2.middleware.shibboleth.idp.session.IdPSessionFilter.doFilter(IdPSessionFilter.java:77) [shibboleth-identityprovider-2.2.0.jar:na]
 at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) [catalina.jar:6.0.29]
 at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) [catalina.jar:6.0.29]
 at edu.internet2.middleware.shibboleth.common.log.SLF4JMDCCleanupFilter.doFilter(SLF4JMDCCleanupFilter.java:51) [shibboleth-common-1.2.0.jar:na]
 at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) [catalina.jar:6.0.29]
 at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) [catalina.jar:6.0.29]
 at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:219) [catalina.jar:6.0.29]
 at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191) [catalina.jar:6.0.29]
 at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127) [catalina.jar:6.0.29]
 at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) [catalina.jar:6.0.29]
 at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) [catalina.jar:6.0.29]
 at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:298) [catalina.jar:6.0.29]
 at org.apache.jk.server.JkCoyoteHandler.invoke(JkCoyoteHandler.java:190) [tomcat-coyote.jar:6.0.29]
 at org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:291) [tomcat-coyote.jar:6.0.29]
 at org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:774) [tomcat-coyote.jar:6.0.29]
 at org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.java:703) [tomcat-coyote.jar:6.0.29]
 at org.apache.jk.common.ChannelSocket$SocketConnection.runIt(ChannelSocket.java:896) [tomcat-coyote.jar:6.0.29]
 at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:690) [tomcat-coyote.jar:6.0.29]
 at java.lang.Thread.run(Thread.java:662) [na:1.6.0_22]
08:54:03.666 - TRACE [edu.internet2.middleware.shibboleth.idp.session.IdPSessionFilter:105] - Attempting to retrieve IdP session cookie.
 
The other difference I see that the process consists of only three HTTP requests on with the old IDP:
 
A get to request the google apps start page which redirects to ->
The google apps login service wich redirects to ->
The old IDP's SAML2 SSo Redirect profile URL with appropriate query string
 
The new idp has two extra request:
A get to request the google apps start page which redirects to ->
The google apps login service wich redirects to ->
The new IDP's SAML2 SSO Redirect profile URL with appropriate query string which redirects to ->
https://shib.northampton.edu/idp/AuthnEngine with no query string which redirects back to ->
The new IDP's SAML2 SSO Redirect profile URL with no query string which gives the produces the error page about decoding the message because the query string has effectively disappeared.
 
As I said, I'm sure that I'm missing something fairly obvious.  I am not using the RemoteUser handler, so that is not the issue.  Any necessary configuration details will be provides on request.
 
Thanks for your time,
 
 
 
Will Fulmer
Database Administrator
Rich 105F
3835 Green Pond Road
Bethlehem, PA 18020
Office Phone: 610-861-5569
Reply | Threaded
Open this post in threaded view
|

Re: "ignoring Assertion without strongly matching NameID in Subject"

Howes, Nick
In reply to this post by lajoie
I think I'd ended up with includeAttributeStatement="false" in the
SAML2SSOProfile while testing and didn't remove it - I've removed it now
so it should now be back to defaults. I think I agree with you about
push on SAML1, but I wouldn't expect a recent version of the SP to be
talking SAML1 to our IdP so the IdP bug shouldn't come up in practice,
so I think I'll leave the SAML1 at the defaults to avoid changing stuff
unnecessarily.

Cheers
Nick

On 06/01/11 14:25, Chad La Joie wrote:

> In general there is no reason to not do attribute push with SAML 2.
>
> Personally I think SAML 1 is fine as well but others disagree based on
> concerns that the attributes are passing through the browser "in the
> clear" (technically, they're slightly obfuscated by base64 encoding).
> My view is that if the browser/host is compromised then attributes
> passing through the browser is really the least of your worries since
> the user just typed in their username/password right before that.
>
> On 1/6/11 9:20 AM, Nick Howes wrote:
>>
>>>> On 1/6/11 7:07 AM, Nick Howes wrote:
>>>>> Okay. In that case I'm not sure how it was working at all against the
>>>>> 2.1.2 IdP.
>>
>> Turns out it was working through attribute push as per Chad's
>> suggestion, which explains the mystery.
>>
>>>>>
>>>>> On 06/01/11 10:40, Chad La Joie wrote:
>>>>>> The IdP has always had the behavior that is causing you problems.
>>>>>> Scott submitted a feature request, which is marked against IdPv3, to
>>>>>> address this:
>>>>>> https://bugs.internet2.edu/jira/browse/SIDPT-23
>>>>>>
>>>>>> On 1/6/11 5:33 AM, Nick Howes wrote:
>>>>>>> Hello,
>>>>>>>
>>>>>>> I'm testing a replacement 2.2 IdP for our currently running 2.1.2
>>>>>>> IdP.
>>>>>>> Testing with a 2.3.1 SP, it will successfully fetch attributes
>>>>>>> from the
>>>>>>> live 2.1.2 IdP but it rejects the attribute response from the
>>>>>>> 2.2 IdP
>>>
>>
>>
>

Reply | Threaded
Open this post in threaded view
|

RE: "ignoring Assertion without strongly matching NameID in Subject"

Cantor, Scott E.
> I think I'd ended up with includeAttributeStatement="false" in the
> SAML2SSOProfile while testing and didn't remove it - I've removed it now
> so it should now be back to defaults. I think I agree with you about
> push on SAML1, but I wouldn't expect a recent version of the SP to be
> talking SAML1 to our IdP so the IdP bug shouldn't come up in practice,
> so I think I'll leave the SAML1 at the defaults to avoid changing stuff
> unnecessarily.

Well, anybody using a legacy WAYF with a new SP would end up using SAML 1. Just FYI. Don't know if that's a concern in your cases or not.

The particular behavior in the SP can simply be toggled off, the setting isn't even on by default, it's just explicitly configured in the file now.

-- Scott


Reply | Threaded
Open this post in threaded view
|

RE: Passive login problem

Cantor, Scott E.
In reply to this post by William Fulmer
> I'm in the process of upgrading my IDP from 2.0.0 to 2.2.0.  I have merged my
> config into the config that comes with 2.2.0 when you do a fresh install.  All
> active authentication requests succeed, even for the SP (Google Apps for
> edu) for which passive authentication request fails.

That's a bug in the IdP, it's fixed in svn. You should be able to find the resolved bug entry, it's marked fixed against v2.2.1 of the IdP project.

-- Scott

Reply | Threaded
Open this post in threaded view
|

Re: "ignoring Assertion without strongly matching NameID in Subject"

Howes, Nick
In reply to this post by Cantor, Scott E.
On 06/01/11 15:23, Cantor, Scott E. wrote:
> The particular behavior in the SP can simply be toggled off, the setting isn't even on by default, it's just explicitly configured in the file now.
Oh yes - I've just seen the subjectMatch="true" attribute.

As my new IdP is no more broken than my current live one, I'll rely on
service providers to configure their SPs appropriately.

Thanks to both.
Nick


Reply | Threaded
Open this post in threaded view
|

RE: Passive login problem

William Fulmer
In reply to this post by Cantor, Scott E.
Thanks for the response, Scott.  Is "SIDP-427 Incorrect handling of
returned authn error in SSO profile handlers" the bug you're referring to?  I never found it because I was to focused on it being connected to passive sessions..
 
I do remember noticing that the logs on the new IDP referred to handling the request as first leg rather than second leg in the logs on the old IDP..
 
Any guess as to the ETA on 2.2.1?  It looks close..
 
 
 
Will Fulmer
Database Administrator
Rich 105F
3835 Green Pond Road
Bethlehem, PA 18020
Office Phone: 610-861-5569
>>> "Cantor, Scott E." <[hidden email]> 1/6/2011 10:25 AM >>>
> I'm in the process of upgrading my IDP from 2.0.0 to 2.2.0.  I have merged my
> config into the config that comes with 2.2.0 when you do a fresh install.  All
> active authentication requests succeed, even for the SP (Google Apps for
> edu) for which passive authentication request fails.

That's a bug in the IdP, it's fixed in svn. You should be able to find the resolved bug entry, it's marked fixed against v2.2.1 of the IdP project.

-- Scott

Reply | Threaded
Open this post in threaded view
|

RE: Passive login problem

Cantor, Scott E.
> Thanks for the response, Scott.  Is "SIDP-427 Incorrect handling of
> returned authn error in SSO profile handlers" the bug you're referring to?  I
> never found it because I was to focused on it being connected to passive
> sessions..

Yeah, should be.
 
> Any guess as to the ETA on 2.2.1?  It looks close..

I don't know, probably not too long.

Do you know offhand when  google uses isPassive?

-- Scott

Reply | Threaded
Open this post in threaded view
|

Re: Passive login problem

lajoie
Administrator
In reply to this post by William Fulmer
Planning on next week.  Have a couple more bugs to stump but I've been
doing testing the last few weeks and things seem good.

On 1/6/11 2:32 PM, William Fulmer wrote:
> Any guess as to the ETA on 2.2.1? It looks close..

--
Chad La Joie
http://itumi.biz
trusted identities, delivered
Reply | Threaded
Open this post in threaded view
|

RE: Passive login problem

William Fulmer
In reply to this post by Cantor, Scott E.
They only use it when you go to their start page for the google app domain
 
usually http://partnerpage.google.com/<your google app domain>
 
If you go directly to any of the other Apps like Mail (https://mail.google.com/a/<your google app domain>, they use Active Auth so it works with the 2.2.0 IDP.

 
Will Fulmer
Database Administrator
Rich 105F
3835 Green Pond Road
Bethlehem, PA 18020
Office Phone: 610-861-5569
>>> "Cantor, Scott E." <[hidden email]> 1/6/2011 2:57 PM >>>
> Thanks for the response, Scott.  Is "SIDP-427 Incorrect handling of
> returned authn error in SSO profile handlers" the bug you're referring to?  I
> never found it because I was to focused on it being connected to passive
> sessions..

Yeah, should be.

> Any guess as to the ETA on 2.2.1?  It looks close..

I don't know, probably not too long.

Do you know offhand when  google uses isPassive?

-- Scott

Reply | Threaded
Open this post in threaded view
|

Re: Passive login problem

Bradley Schwoerer
In reply to this post by lajoie
We have been running on everything in SVN plus a few other proposed patches
and everything has been working very well.  For us the three biggest changes
that eliminated 80% of the errors has been SIDP-446, SIDP-432, and SIDP-453.
Adding a robots.txt helped a lot too, but those weren't user generated
errors.

Chad, thank you for all of your work on this.


-Bradley



On 1/6/11 2:54 PM, "Chad La Joie" <[hidden email]> wrote:

> Planning on next week.  Have a couple more bugs to stump but I've been
> doing testing the last few weeks and things seem good.
>
> On 1/6/11 2:32 PM, William Fulmer wrote:
>> Any guess as to the ETA on 2.2.1? It looks close..


Reply | Threaded
Open this post in threaded view
|

Re: Passive login problem

Halm Reusser
On 07.01.11 03:28, Bradley Schwoerer wrote:
> Adding a robots.txt helped a lot too, but those weren't user
> generated errors.

Nice. May I ask you to post it here. Or even better document it on
spaces, https://spaces.internet2.edu/display/SHIB2/Productionalization
would be adequate. I'm sure it helps to improve log monitoring.

-Halm
Reply | Threaded
Open this post in threaded view
|

RE: Passive login problem

William Fulmer
In reply to this post by Cantor, Scott E.
I installed the SVN version of the IDP today and it does fix my passive session problem...

 
Will Fulmer
Database Administrator
Rich 105F
3835 Green Pond Road
Bethlehem, PA 18020
Office Phone: 610-861-5569
 
>>> "Cantor, Scott E." <[hidden email]> 1/6/2011 2:57 PM >>>
> Thanks for the response, Scott.  Is "SIDP-427 Incorrect handling of
> returned authn error in SSO profile handlers" the bug you're referring to?  I
> never found it because I was to focused on it being connected to passive
> sessions..

Yeah, should be.

> Any guess as to the ETA on 2.2.1?  It looks close..

I don't know, probably not too long.

Do you know offhand when  google uses isPassive?

-- Scott

Reply | Threaded
Open this post in threaded view
|

Re: Passive login problem

Bradley Schwoerer
In reply to this post by Halm Reusser
Halm,

Thanks for the suggestion.  I added a page under IDP called Other Tips
https://spaces.internet2.edu/display/SHIB2/IdPTips.

-Bradley


On 1/7/11 5:30 AM, "Halm Reusser" <[hidden email]> wrote:

> On 07.01.11 03:28, Bradley Schwoerer wrote:
>> Adding a robots.txt helped a lot too, but those weren't user
>> generated errors.
>
> Nice. May I ask you to post it here. Or even better document it on
> spaces, https://spaces.internet2.edu/display/SHIB2/Productionalization
> would be adequate. I'm sure it helps to improve log monitoring.
>
> -Halm