[Shib-Users] Google Apps SSO

[Baron Fujimoto]

I'm trying to enable SSO for Google Apps using the Shibboleth IdP (2.1.2)
with the instructions found at:

<http://code.google.com/intl/en/apis/apps/articles/shibboleth2.0.html>

If I try to access an URL that requires login (e.g.
<mail.google.com/a/gtest.hawaii.edu>), I'm redirected to our Sign-in URL
page, and after authenticating there, sent to the URL specified in the
Location value of the AssertionConsumerService element for Google's
EntityDescriptor in the metadata. However, I get the following error:

Invalid Email
We are unable to process your request at this time, please try again later.

A possible complication is that we are also using the jasig CASFilter as
described at:

<https://www.switch.ch/aai/docs/shibboleth/SWITCH/1.3/idp/install-cas.html>

but the IdP config appears to work as expected when using the TestShib SP
as the relying party <https://sp.testshib.org/shibboleth-sp>.

Any ideas on what may be wrong here?

I don't see anything obvious in our IdP logs:

13:25:04.136 - INFO [Shibboleth-Access:72] - 20090817T232504Z|172.16.1.15|www.test.hawaii.edu:443|/profile/SAML2/Redirect/SSO|
13:25:04.138 - DEBUG [edu.internet2.middleware.shibboleth.idp.profile.IdPProfileHandlerManager:85] - shibboleth.HandlerManager: Looking up profile handler for request path: /SAML2/Redirect/SSO
13:25:04.139 - 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
13:25:04.140 - DEBUG [edu.internet2.middleware.shibboleth.idp.profile.saml2.SSOProfileHandler:144] - Incoming request does not contain a login context, processing as first leg of request
13:25:04.141 - DEBUG [edu.internet2.middleware.shibboleth.idp.profile.saml2.SSOProfileHandler:288] - Decoding message with decoder binding urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect
13:25:04.151 - DEBUG [edu.internet2.middleware.shibboleth.common.relyingparty.provider.SAMLMDRelyingPartyConfigurationManager:126] - Looking up relying party configuration for google.com
13:25:04.153 - DEBUG [edu.internet2.middleware.shibboleth.common.relyingparty.provider.SAMLMDRelyingPartyConfigurationManager:128] - Custom relying party configuration found for google.com
13:25:04.155 - DEBUG [edu.internet2.middleware.shibboleth.idp.profile.saml2.SSOProfileHandler:307] - Decoded request
13:25:04.157 - DEBUG [edu.internet2.middleware.shibboleth.common.relyingparty.provider.SAMLMDRelyingPartyConfigurationManager:126] - Looking up relying party configuration for google.com
13:25:04.158 - DEBUG [edu.internet2.middleware.shibboleth.common.relyingparty.provider.SAMLMDRelyingPartyConfigurationManager:128] - Custom relying party configuration found for google.com
13:25:04.159 - DEBUG [edu.internet2.middleware.shibboleth.idp.profile.saml2.SSOProfileHandler:180] - Creating login context and transferring control to authentication engine
13:25:04.171 - DEBUG [edu.internet2.middleware.shibboleth.idp.authn.AuthenticationEngine:262] - Processing incoming request
13:25:04.173 - DEBUG [edu.internet2.middleware.shibboleth.idp.authn.AuthenticationEngine:292] - Beginning user authentication process.
13:25:04.174 - DEBUG [edu.internet2.middleware.shibboleth.idp.authn.AuthenticationEngine:296] - Existing IdP session available for principal baron
13:25:04.175 - DEBUG [edu.internet2.middleware.shibboleth.idp.authn.AuthenticationEngine:351] - Filtering configured login handlers by requested athentication methods.
13:25:04.176 - DEBUG [edu.internet2.middleware.shibboleth.idp.authn.AuthenticationEngine:352] - Configured LoginHandlers: {urn:oasis:names:tc:SAML:2.0:ac:classes:unspecified=edu.internet2.middleware.shibboleth.idp.authn.provider.RemoteUserLoginHandler@1f40e1f, urn:oasis:names:tc:SAML:2.0:ac:classes:PreviousSession=edu.internet2.middleware.shibboleth.idp.authn.provider.PreviousSessionLoginHandler@1cb2dd1}
13:25:04.178 - DEBUG [edu.internet2.middleware.shibboleth.idp.authn.AuthenticationEngine:353] - Requested authentication methods: org.opensaml.xml.util.LazyList@1061299
13:25:04.179 - DEBUG [edu.internet2.middleware.shibboleth.idp.authn.AuthenticationEngine:300] - Possible authentication handlers for this request: {urn:oasis:names:tc:SAML:2.0:ac:classes:unspecified=edu.internet2.middleware.shibboleth.idp.authn.provider.RemoteUserLoginHandler@1f40e1f, urn:oasis:names:tc:SAML:2.0:ac:classes:PreviousSession=edu.internet2.middleware.shibboleth.idp.authn.provider.PreviousSessionLoginHandler@1cb2dd1}
13:25:04.180 - DEBUG [edu.internet2.middleware.shibboleth.idp.authn.AuthenticationEngine:313] - Possible authentication handlers after filtering: {urn:oasis:names:tc:SAML:2.0:ac:classes:unspecified=edu.internet2.middleware.shibboleth.idp.authn.provider.RemoteUserLoginHandler@1f40e1f, urn:oasis:names:tc:SAML:2.0:ac:classes:PreviousSession=edu.internet2.middleware.shibboleth.idp.authn.provider.PreviousSessionLoginHandler@1cb2dd1}
13:25:04.182 - DEBUG [edu.internet2.middleware.shibboleth.idp.authn.AuthenticationEngine:326] - Authenticating user with login handler of type edu.internet2.middleware.shibboleth.idp.authn.provider.PreviousSessionLoginHandler
13:25:04.184 - DEBUG [edu.internet2.middleware.shibboleth.idp.authn.provider.PreviousSessionLoginHandler:111] - Using existing IdP session for baron
13:25:04.185 - DEBUG [edu.internet2.middleware.shibboleth.idp.authn.AuthenticationEngine:208] - Returning control to authentication engine
13:25:04.187 - DEBUG [edu.internet2.middleware.shibboleth.idp.authn.AuthenticationEngine:262] - Processing incoming request
13:25:04.188 - DEBUG [edu.internet2.middleware.shibboleth.idp.authn.AuthenticationEngine:523] - Completing user authentication process
13:25:04.190 - DEBUG [edu.internet2.middleware.shibboleth.idp.authn.AuthenticationEngine:576] - Validating authentication was performed successfully
13:25:04.191 - DEBUG [edu.internet2.middleware.shibboleth.idp.authn.AuthenticationEngine:668] - Updating session information for principal baron
13:25:04.193 - DEBUG [edu.internet2.middleware.shibboleth.idp.authn.AuthenticationEngine:682] - Recording authentication and service information in Shibboleth session for principal: baron
13:25:04.195 - DEBUG [edu.internet2.middleware.shibboleth.idp.authn.AuthenticationEngine:551] - User baron authenticated with method urn:oasis:names:tc:SAML:2.0:ac:classes:PreviousSession
13:25:04.196 - DEBUG [edu.internet2.middleware.shibboleth.idp.authn.AuthenticationEngine:227] - Returning control to profile handler at: /profile/SAML2/Redirect/SSO
13:25:04.198 - INFO [Shibboleth-Access:72] - 20090817T232504Z|172.16.1.15|www.test.hawaii.edu:443|/profile/SAML2/Redirect/SSO|
13:25:04.200 - DEBUG [edu.internet2.middleware.shibboleth.idp.profile.IdPProfileHandlerManager:85] - shibboleth.HandlerManager: Looking up profile handler for request path: /SAML2/Redirect/SSO
13:25:04.202 - 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
13:25:04.203 - DEBUG [edu.internet2.middleware.shibboleth.idp.profile.saml2.SSOProfileHandler:147] - Incoming request contains a login context, processing as second leg of request
13:25:04.205 - DEBUG [edu.internet2.middleware.shibboleth.common.relyingparty.provider.SAMLMDRelyingPartyConfigurationManager:126] - Looking up relying party configuration for google.com
13:25:04.207 - DEBUG [edu.internet2.middleware.shibboleth.common.relyingparty.provider.SAMLMDRelyingPartyConfigurationManager:128] - Custom relying party configuration found for google.com
13:25:04.214 - DEBUG [edu.internet2.middleware.shibboleth.idp.profile.saml2.AbstractSAML2ProfileHandler:417] - Resolving attributes for principal baron of SAML request from relying party google.com
13:25:04.216 - DEBUG [edu.internet2.middleware.shibboleth.common.attribute.resolver.provider.ShibbolethAttributeResolver:120] - shibboleth.AttributeResolver resolving attributes for principal baron
13:25:04.218 - DEBUG [edu.internet2.middleware.shibboleth.common.attribute.resolver.provider.ShibbolethAttributeResolver:258] - Specific attributes for principal baron were not requested, resolving all attributes.
13:25:04.220 - DEBUG [edu.internet2.middleware.shibboleth.common.attribute.resolver.provider.ShibbolethAttributeResolver:294] - Resolving attribute UhEduPerson_cn for principal baron
13:25:04.221 - DEBUG [edu.internet2.middleware.shibboleth.common.attribute.resolver.provider.ShibbolethAttributeResolver:334] - Resolving data connector UH_LDAP for principal baron
13:25:04.228 - DEBUG [edu.internet2.middleware.shibboleth.common.attribute.resolver.provider.dataConnector.LdapDataConnector:765] - Search filter: (uid=baron)
13:25:04.230 - DEBUG [edu.internet2.middleware.shibboleth.common.attribute.resolver.provider.dataConnector.LdapDataConnector:781] - Retrieving attributes from LDAP
13:25:04.435 - DEBUG [edu.internet2.middleware.shibboleth.common.attribute.resolver.provider.dataConnector.LdapDataConnector:882] - Found the following attribute: sn=[Fujimoto]
13:25:04.438 - DEBUG [edu.internet2.middleware.shibboleth.common.attribute.resolver.provider.dataConnector.LdapDataConnector:882] - Found the following attribute: cn=[Baron K Fujimoto]
13:25:04.440 - DEBUG [edu.internet2.middleware.shibboleth.common.attribute.resolver.provider.dataConnector.LdapDataConnector:882] - Found the following attribute: givenName=[Baron]
13:25:04.442 - DEBUG [edu.internet2.middleware.shibboleth.common.attribute.resolver.provider.dataConnector.LdapDataConnector:882] - Found the following attribute: displayName=[Baron K Fujimoto]
13:25:04.444 - DEBUG [edu.internet2.middleware.shibboleth.common.attribute.resolver.provider.ShibbolethAttributeResolver:316] - Resolved attribute UhEduPerson_cn containing 1 values
13:25:04.446 - DEBUG [edu.internet2.middleware.shibboleth.common.attribute.resolver.provider.ShibbolethAttributeResolver:294] - Resolving attribute UhEduPerson_displayName for principal baron
13:25:04.448 - DEBUG [edu.internet2.middleware.shibboleth.common.attribute.resolver.provider.ShibbolethAttributeResolver:316] - Resolved attribute UhEduPerson_displayName containing 1 values
13:25:04.450 - DEBUG [edu.internet2.middleware.shibboleth.common.attribute.resolver.provider.ShibbolethAttributeResolver:294] - Resolving attribute transientId for principal baron
13:25:04.453 - DEBUG [edu.internet2.middleware.shibboleth.common.attribute.resolver.provider.ShibbolethAttributeResolver:316] - Resolved attribute transientId containing 1 values
13:25:04.455 - DEBUG [edu.internet2.middleware.shibboleth.common.attribute.resolver.provider.ShibbolethAttributeResolver:294] - Resolving attribute principal for principal baron
13:25:04.457 - DEBUG [edu.internet2.middleware.shibboleth.common.attribute.resolver.provider.ShibbolethAttributeResolver:316] - Resolved attribute principal containing 1 values
13:25:04.459 - DEBUG [edu.internet2.middleware.shibboleth.common.attribute.resolver.provider.ShibbolethAttributeResolver:138] - shibboleth.AttributeResolver resolved, for principal baron, the attributes: [UhEduPerson_cn, UhEduPerson_displayName, transientId, principal]
13:25:04.461 - DEBUG [edu.internet2.middleware.shibboleth.common.attribute.filtering.provider.ShibbolethAttributeFilteringEngine:70] - shibboleth.AttributeFilterEngine filtering 4 attributes for principal baron
13:25:04.463 - DEBUG [edu.internet2.middleware.shibboleth.common.attribute.filtering.provider.ShibbolethAttributeFilteringEngine:122] - Evaluating if filter policy releaseTransientIdToAnyone is active for principal baron
13:25:04.465 - DEBUG [edu.internet2.middleware.shibboleth.common.attribute.filtering.provider.ShibbolethAttributeFilteringEngine:131] - Filter policy releaseTransientIdToAnyone is active for principal baron
13:25:04.467 - DEBUG [edu.internet2.middleware.shibboleth.common.attribute.filtering.provider.ShibbolethAttributeFilteringEngine:156] - Processing permit value rule for attribute transientId for principal baron
13:25:04.468 - DEBUG [edu.internet2.middleware.shibboleth.common.attribute.filtering.provider.ShibbolethAttributeFilteringEngine:122] - Evaluating if filter policy releaseUhEduPerson_displayNameToTestShib is active for principal baron
13:25:04.470 - DEBUG [edu.internet2.middleware.shibboleth.common.attribute.filtering.provider.ShibbolethAttributeFilteringEngine:126] - Filter policy releaseUhEduPerson_displayNameToTestShib is not active for principal baron
13:25:04.472 - DEBUG [edu.internet2.middleware.shibboleth.common.attribute.filtering.provider.ShibbolethAttributeFilteringEngine:122] - Evaluating if filter policy null is active for principal baron
13:25:04.474 - DEBUG [edu.internet2.middleware.shibboleth.common.attribute.filtering.provider.ShibbolethAttributeFilteringEngine:131] - Filter policy null is active for principal baron
13:25:04.476 - DEBUG [edu.internet2.middleware.shibboleth.common.attribute.filtering.provider.ShibbolethAttributeFilteringEngine:156] - Processing permit value rule for attribute principal for principal baron
13:25:04.478 - DEBUG [edu.internet2.middleware.shibboleth.common.attribute.filtering.provider.ShibbolethAttributeFilteringEngine:101] - Removing attribute from return set, no more values: UhEduPerson_cn
13:25:04.480 - DEBUG [edu.internet2.middleware.shibboleth.common.attribute.filtering.provider.ShibbolethAttributeFilteringEngine:101] - Removing attribute from return set, no more values: UhEduPerson_displayName
13:25:04.482 - DEBUG [edu.internet2.middleware.shibboleth.common.attribute.filtering.provider.ShibbolethAttributeFilteringEngine:106] - Filtered attributes for principal baron. The following attributes remain: [transientId, principal]
13:25:04.484 - DEBUG [edu.internet2.middleware.shibboleth.idp.profile.saml2.AbstractSAML2ProfileHandler:443] - Creating attribute statement in response to SAML request okclljopeijfohkjibcpdkcnfdfodnfikbhkllea from relying party google.com
13:25:04.486 - DEBUG [edu.internet2.middleware.shibboleth.common.attribute.provider.ShibbolethSAML2AttributeAuthority:225] - Attribute transientId was not encoded because no SAML2AttributeEncoder was attached to it.
13:25:04.488 - DEBUG [edu.internet2.middleware.shibboleth.common.attribute.provider.ShibbolethSAML2AttributeAuthority:225] - Attribute principal was not encoded because no SAML2AttributeEncoder was attached to it.
13:25:04.490 - DEBUG [edu.internet2.middleware.shibboleth.common.attribute.provider.ShibbolethSAML2AttributeAuthority:127] - No attributes remained after encoding and filtering by value, no attribute statement built
13:25:04.493 - DEBUG [edu.internet2.middleware.shibboleth.idp.profile.saml2.AbstractSAML2ProfileHandler:733] - Building assertion NameID for principal/relying party:baron/google.com
13:25:04.495 - DEBUG [edu.internet2.middleware.shibboleth.idp.profile.saml2.AbstractSAML2ProfileHandler:774] - SP indicated no preferred name formats.
13:25:04.497 - DEBUG [edu.internet2.middleware.shibboleth.idp.profile.saml2.AbstractSAML2ProfileHandler:785] - Using attribute transientId supporting NameID format urn:oasis:names:tc:SAML:2.0:nameid-format:transient to create the NameID.
13:25:04.499 - DEBUG [edu.internet2.middleware.shibboleth.idp.profile.saml2.AbstractSAML2ProfileHandler:511] - Determining if SAML assertion to relying party google.com should be signed
13:25:04.501 - DEBUG [edu.internet2.middleware.shibboleth.idp.profile.saml2.AbstractSAML2ProfileHandler:536] - Entity metadata for relying party google.com indicates to sign assertions: false
13:25:04.503 - DEBUG [edu.internet2.middleware.shibboleth.idp.profile.AbstractSAMLProfileHandler:541] - Encoding response to SAML request okclljopeijfohkjibcpdkcnfdfodnfikbhkllea from relying party google.com
13:25:04.554 - WARN [org.opensaml.saml2.binding.encoding.BaseSAML2MessageEncoder:88] - Relay state exceeds 80 bytes, some application may not support this.
13:25:04.573 - INFO [Shibboleth-Audit:898] - 20090817T232504Z|urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect|okclljopeijfohkjibcpdkcnfdfodnfikbhkllea|google.com|urn:mace:shibboleth:2.0:profiles:saml2:sso|https://www.test.hawaii.edu/idp/shibboleth|urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST|_6920b3ad7f78db5b52c9d86be63479a2|baron|urn:oasis:names:tc:SAML:2.0:ac:classes:PreviousSession||_b855b68f3b51051b716ecb3000aa5d7c|_7148875b220496787e75b0cc42fcb955,|

--
Baron Fujimoto <ba...@hawaii.edu> :: UH Information Technology Services
minutas cantorum, minutas balorum, minutas carboratum desendus pantorum

[Peter Schober]

* Baron Fujimoto <ba...@hawaii.edu> [2009-08-18 03:10]:

> If I try to access an URL that requires login (e.g.
> <mail.google.com/a/gtest.hawaii.edu>), I'm redirected to our Sign-in URL
> page, and after authenticating there, sent to the URL specified in the
> Location value of the AssertionConsumerService element for Google's
> EntityDescriptor in the metadata. However, I get the following error:
>
> Invalid Email
> We are unable to process your request at this time, please try again later.

Search the archives for "Shibboleth with Google Apps",
-peter

[Earle II,Timothy C]

It sounds to me like you're not releasing the proper attribute. Is it a 1:1 mapping between your internal ID and the Google Apps e-mail address. For example. Joe Student will login with studj and the cooresponding mailbox will be st...@college.edu. Google calls this attribute NameID, so you should be releasing the principle (what they logged in with) to them as NameID.

Tim Earle
Internet & Server Systems
The University of Akron
________________________________________
From: Baron Fujimoto [ba...@hawaii.edu]
Sent: Monday, August 17, 2009 21:09
To: shibbole...@internet2.edu
Subject: [Shib-Users] Google Apps SSO

[Michael J. Wheeler]

I wrestled with this for days trying to get it all to work with Google
Apps. After looking through the logs, Tim's guess is spot on. After looking
at the logs this line sticks out:

13:25:04.497 - DEBUG
[edu.internet2.middleware.shibboleth.idp.profile.saml2.AbstractSAML2ProfileHandler:785]
- Using attribute transientId supporting NameID format
urn:oasis:names:tc:SAML:2.0:nameid-format:transient to create the NameID.

It's using transientId as the attribute to release to Google as opposed to
the user's principal/email address. For right or wrong, I got around it by
what I feel is a hack. I wrote an attribute filter to release the
transientId to everyone BUT Google -- that's the only way I could make it
work. We haven't seen any issues and have been using Google Apps with
Shibboleth in production for months with a couple thousand accounts.

Here are my attribute filters (in attribute-filter.xml) that have to do
with Google Apps:

<!-- Google (gus.pittstate.edu) Policy; Releases psuGUSEmailAddress to
Google Apps -->
<AttributeFilterPolicy id="google.com/a/gus.pittstate.edu">
<PolicyRequirementRule xsi:type="basic:AttributeRequesterString"
value="google.com/a/gus.pittstate.edu" />

<AttributeRule attributeID="psuGUSEmailAddress">
<PermitValueRule xsi:type="basic:ANY" />
</AttributeRule>

</AttributeFilterPolicy>

<!-- Release the transient ID to anyone (except google, they need
psuGUSEmailAddress) -->
<AttributeFilterPolicy id="releaseTransientIdToAnyone">
<PolicyRequirementRule xsi:type="basic:NOT">
<basic:Rule xsi:type="basic:AttributeRequesterString"
value="google.com/a/gus.pittstate.edu" />
</PolicyRequirementRule>

<AttributeRule attributeID="transientId">
<PermitValueRule xsi:type="basic:ANY" />
</AttributeRule>

</AttributeFilterPolicy>

--
Michael J. Wheeler
Assistant Director, Systems and Networking
Pittsburg State University
Phone: 620-235-4610
E-mail: mwhe...@pittstate.edu

[Chad La Joie]

That's how you do it. The attribute filter controls the release of
information from the IdP.

As a random aside, is that really Google's entity ID? It's not a valid
ID if it is. Oh well, Google has long since moved in to the Microsoft
mentality of "following" specs, no big surprise I guess.

Michael J. Wheeler wrote:
> It's using transientId as the attribute to release to Google as opposed
> to the user's principal/email address. For right or wrong, I got around
> it by what I feel is a hack. I wrote an attribute filter to release the
> transientId to everyone BUT Google -- that's the only way I could make
> it work. We haven't seen any issues and have been using Google Apps with
> Shibboleth in production for months with a couple thousand accounts.

--
SWITCH
Serving Swiss Universities
--------------------------
Chad La Joie, Software Engineer, Net Services
Werdstrasse 2, P.O. Box, 8021 Zürich, Switzerland
phone +41 44 268 15 75, fax +41 44 268 15 68
chad....@switch.ch, http://www.switch.ch

[Jim Fox]

>
> As a random aside, is that really Google's entity ID? It's not a
> valid
> ID if it is. Oh well, Google has long since moved in to the Microsoft
> mentality of "following" specs, no big surprise I guess.

Google's entity id for us is just "google.com".

Jim

[Chad La Joie]

Which is not a valid entity ID.

--

[Jim Fox]

Not valid, but the one they use.

Jim

[Baron Fujimoto]

On Tue, Aug 18, 2009 at 08:46:25AM -0500, Michael J. Wheeler wrote:
> [...]

> After looking at the logs this line sticks out:
>
> 13:25:04.497 - DEBUG
> [edu.internet2.middleware.shibboleth.idp.profile.saml2.AbstractSAML2ProfileHandler:785]
> - Using attribute transientId supporting NameID format
> urn:oasis:names:tc:SAML:2.0:nameid-format:transient to create the NameID.
>
> It's using transientId as the attribute to release to Google as opposed
> to the user's principal/email address. For right or wrong, I got around
> it by what I feel is a hack. I wrote an attribute filter to release the
> transientId to everyone BUT Google -- that's the only way I could make it
> work. We haven't seen any issues and have been using Google Apps with
> Shibboleth in production for months with a couple thousand accounts.

That appears to have been the problem. Even though there was a specific
attribute filter policy for the defined attribute "principal", unless the
transientID was specifically NOT released to Google, it would fail.

> <!-- Release the transient ID to anyone (except google, they need
> psuGUSEmailAddress) -->
> <AttributeFilterPolicy id="releaseTransientIdToAnyone">
> <PolicyRequirementRule xsi:type="basic:NOT">
> <basic:Rule xsi:type="basic:AttributeRequesterString"
> value="google.com/a/gus.pittstate.edu" />
> </PolicyRequirementRule>
>
> <AttributeRule attributeID="transientId">
> <PermitValueRule xsi:type="basic:ANY" />
> </AttributeRule>
>
> </AttributeFilterPolicy>

Thank you nui loa and mahalo very much! :)

[Chad La Joie]

The IdP name identifier docs tell you how it selects which attribute to
use as the name identifier. So this behavior shouldn't be a surprise to
anyone.

Baron Fujimoto wrote:
> That appears to have been the problem. Even though there was a specific
> attribute filter policy for the defined attribute "principal", unless the
> transientID was specifically NOT released to Google, it would fail.

[Michael J. Wheeler]

Chad,

With all due respect, it makes a lot of sense to you because you've been
doing it for so long and are intimately familiar with SAML and Shibboleth.
For those of us that are trying to overcome both the SAML and Shibboleth
learning curve at the same time, we may read a particular piece of
documentation, but it may not make sense because we're not familiar enough
with the context in which it applies.

Also, the documentation has been great in some areas and lacking in others.
I remember digging trying to figure out how to get the IdP metadata (I
didn't know it was available by just hitting a particular URL), but when I
finally found the info on it (it was buried as I remember) I found myself
thinking, "Why isn't this right on the 'setting up a SP' page?"

I've also felt a bit reluctant to suggest documentation changes because you
guys can be a bit terse with us newbies -- whether it is intentional or
not. Again, I mean no disrespect, but don't forget to think about it from
our point of view sometimes.

--
Michael J. Wheeler
Assistant Director, Systems and Networking
Pittsburg State University
Phone: 620-235-4610
E-mail: mwhe...@pittstate.edu

[Peter Schober]

* Michael J. Wheeler <mwhe...@pittstate.edu> [2009-08-19 15:51]:

> don't forget to think about it from our point of view sometimes.

The extent to which the current docs do not meet your requirements
is an approximation of the degree to which "seeing things from others'
point of view" is impossible (and vice versa).
-peter

[Chad La Joie]

Michael J. Wheeler wrote:
> With all due respect, it makes a lot of sense to you because you've been
> doing it for so long and are intimately familiar with SAML and
> Shibboleth. For those of us that are trying to overcome both the SAML
> and Shibboleth learning curve at the same time, we may read a particular
> piece of documentation, but it may not make sense because we're not
> familiar enough with the context in which it applies.

So, here's the thinking we used for this case. If some one doesn't
understand Shib, they'd start at the section called "Understanding
Shibboleth". If they wanted to know about name identifiers they select
"Name Identifiers and Attributes" and upon reading would find things
like "Because of their similarities [referring to name identifiers and
attributes] though, Shibboleth 2 considers the name identifier to simply
be part of the collective set of attributes that makes up a digital
identity." and "it allows the deployer to determine which relying
parties get which name identifiers via attribute filter policies".

Do you have suggestions on making that clearer? I will note that some
one recently did offer a couple suggestions and so that page has been
updated (and was, I think, made clearer because of it).

> Also, the documentation has been great in some areas and lacking in
> others. I remember digging trying to figure out how to get the IdP
> metadata (I didn't know it was available by just hitting a particular
> URL), but when I finally found the info on it (it was buried as I
> remember) I found myself thinking, "Why isn't this right on the 'setting
> up a SP' page?"

Because doing it that way isn't secure. Now, in the case you brought
up, some one did actually note this as information that was missing. So
the following was added on Jan 21, 2008

"metadata/ - This is the directory in which the IdP will store its
metadata, in a file called _idp-metadata.xml"

Maybe you installed your IdP before that. But this is again one of
those things that I don't know how to make any clearer. So, if you
didn't install your IdP before then and if this was confusing you need
to say *what* was confusing or we aren't going to get it fixed.

> I've also felt a bit reluctant to suggest documentation changes because
> you guys can be a bit terse with us newbies -- whether it is intentional
> or not. Again, I mean no disrespect, but don't forget to think about it
> from our point of view sometimes.

Well, then the docs will stay as they are. With a *very* few exceptions
anytime we ask people what exactly they don't understand about the docs
we get nothing useful in response. With out telling us exactly what is
unclear nothing is going to change.

Since you brought up the point of view thing, though, have you
considered what it's like trying to write reasonable documentation for a
piece of software that is expected to plug in to any existing IT
infrastructure? Where reasonable is defined as documentation that is
maintainable by its authors as well as understandable by all people who
ever download the software and try using it with infrastructure which
they may, or may not, know anything about. How would you do with a
similar task? Do you have guidelines and pointers for doing it well?

[Baron Fujimoto]

On Wed, Aug 19, 2009 at 04:43:09PM +0200, Chad La Joie wrote:
> Michael J. Wheeler wrote:
>> With all due respect, it makes a lot of sense to you because you've
>> been doing it for so long and are intimately familiar with SAML and
>> Shibboleth. For those of us that are trying to overcome both the SAML
>> and Shibboleth learning curve at the same time, we may read a
>> particular piece of documentation, but it may not make sense because
>> we're not familiar enough with the context in which it applies.
>
> So, here's the thinking we used for this case. If some one doesn't
> understand Shib, they'd start at the section called "Understanding
> Shibboleth". If they wanted to know about name identifiers they select
> "Name Identifiers and Attributes" and upon reading would find things
> like "Because of their similarities [referring to name identifiers and
> attributes] though, Shibboleth 2 considers the name identifier to simply
> be part of the collective set of attributes that makes up a digital
> identity." and "it allows the deployer to determine which relying
> parties get which name identifiers via attribute filter policies".

In Michael's defense, I will confess to having had a very similar
experience. When the you're new to Shibboleth and SAML, you don't have
much in the way of contextual hooks to hang any particular piece of info,
nor have you yet developed an intuition as to what will be important vs.
just FYI (maybe it's all important). When I first got involved with Shib,
I did read through the "Understanding Shibboleth" links, though obviously
I did not fully remember or grok everything presented there.

I had to move on to other installation and configuration tasks. I think
I did this before they were reorganized or rewritten a bit, since they
seem clearer now (though perhaps that is just the benefit of hindsight and
a little more experience). I do recall that finding the appropriate
documentation was often frustrating. When I eventually found what I
needed, it was usually sufficient and I could progress, but it seemed like
half the challenge was just trying to figure out what I should be looking
for in the first place (context again, mainly, I think).

When I encountered this particular problem, I wrestled with it for a while
but again found myself struggling with where to focus the troubleshooting.
All I can say is that for myself the problem was non-obvious given my
level of experience, Google's relative lack of documentation, and the
Shib-related log info at my disposal. Even having reviewed the "Name
Identifiers and Attributes" page again, it's not clear to me why releasing
the transientID to Google, in addition to the defined "principal"
attribute results in failure.

I certainly sympathize here as well. As I go through the process, I try
to keep in back of my mind what I think would make it better. Usually, I
don't have a good answer, other than "I wish I knew/had known that this
is what I needed". I understand the software is very complex and very
flexible, which contributes to the challenge. Even though you can't cover
all the possibilities, maybe more case studies or concrete examples would
be helpful. I'm also working on internally documenting our experience and
configuration that we could probably contribute back when done.

[Scott Cantor]

Baron Fujimoto wrote on 2009-08-19:
> All I can say is that for myself the problem was non-obvious given my
> level of experience, Google's relative lack of documentation, and the
> Shib-related log info at my disposal. Even having reviewed the "Name
> Identifiers and Attributes" page again, it's not clear to me why releasing
> the transientID to Google, in addition to the defined "principal"
> attribute results in failure.

It fails because Google is requiring a particular kind of NameID and if you
leave the IdP with two types to pick from and it picks the wrong one, it
fails.

With respect to your suggestion about examples, I'd point out that I don't
use that service and neither does Chad. Seems like we'd be a lousy choice to
document it, and the wiki is, as always, open for editing.

Everybody involved with the project knows that the contextual material is
lacking. I just spent about 12 man-hours writing metadata documentation and
I have no idea if it's helping anybody or not, but that's scratching the
surface of the months of work it would take to document things. Instead,
we're paid to write new code. I've made that point many times.

-- Scott

[Chad La Joie]

Baron Fujimoto wrote:
> When I encountered this particular problem, I wrestled with it for a while
> but again found myself struggling with where to focus the troubleshooting.
> All I can say is that for myself the problem was non-obvious given my
> level of experience, Google's relative lack of documentation, and the
> Shib-related log info at my disposal. Even having reviewed the "Name
> Identifiers and Attributes" page again, it's not clear to me why releasing
> the transientID to Google, in addition to the defined "principal"
> attribute results in failure.

I don't see this as a Shibboleth documentation problem. Google has an
application with certain requirements. Other applications have other
requirements. The apps need to document what it is they need. It's not
really any different than an LDAP enabled application. It's not
OpenLDAP's job to document how Confluence uses the LDAP directory.

[Baron Fujimoto]

On Wed, Aug 19, 2009 at 03:21:44PM -0400, Scott Cantor wrote:
: Baron Fujimoto wrote on 2009-08-19:
: > All I can say is that for myself the problem was non-obvious given my

: > level of experience, Google's relative lack of documentation, and the
: > Shib-related log info at my disposal. Even having reviewed the "Name
: > Identifiers and Attributes" page again, it's not clear to me why releasing
: > the transientID to Google, in addition to the defined "principal"
: > attribute results in failure.

:
: It fails because Google is requiring a particular kind of NameID and if you

: leave the IdP with two types to pick from and it picks the wrong one, it
: fails.

I had sort of gathered as much based on the help from this list, but if
I was supposed to glean that from the the documentation I had seen...
well, I guess I just whiffed that then.

: With respect to your suggestion about examples, I'd point out that I don't

: use that service and neither does Chad. Seems like we'd be a lousy choice to
: document it, and the wiki is, as always, open for editing.
:
: Everybody involved with the project knows that the contextual material is
: lacking. I just spent about 12 man-hours writing metadata documentation and
: I have no idea if it's helping anybody or not, but that's scratching the
: surface of the months of work it would take to document things. Instead,
: we're paid to write new code. I've made that point many times.

It wasn't my intention to disparage anyone's efforts here. I'm grateful
for the work and effort you folks put into Shib, nor was I necessarily
expecting a specific example for Google. I'm just relaying my own
experience so far. I'm willing to contribute it back to the community
as well - once I feel I have enough of a handle on it so it's not the
blind leading the blind.

[Scott Cantor]

Baron Fujimoto wrote on 2009-08-19:
> I had sort of gathered as much based on the help from this list, but if
> I was supposed to glean that from the the documentation I had seen...
> well, I guess I just whiffed that then.

I think that is the expectation (this is IdP side so I haven't looked all
that closely), so again, if it doesn't work, we have to have specific
suggestions on what to improve.

> It wasn't my intention to disparage anyone's efforts here. I'm grateful
> for the work and effort you folks put into Shib, nor was I necessarily
> expecting a specific example for Google.

I think it's perfectly reasonable to have an example for Google, maybe it's
even a "good" case study (where "good" means something somewhat other than
the English meaning). But if there isn't one, that isn't because of us,
that's all I'm pointing out.

-- Scott

[Chad La Joie]

I guess I should also say that this morning (my time) I started to work
on a way of allow more examples to be added without those examples also
confusing the main documentation (another issue we run in to on some
pages). A couple people are looking at it now and once their initial
feedback is given I'll rev a couple other pages in the same fashion and
ask for more feedback.

--

[Christopher A Bongaarts]

In the immortal words of Baron Fujimoto:

> It wasn't my intention to disparage anyone's efforts here. I'm grateful
> for the work and effort you folks put into Shib, nor was I necessarily
> expecting a specific example for Google. I'm just relaying my own
> experience so far. I'm willing to contribute it back to the community
> as well - once I feel I have enough of a handle on it so it's not the
> blind leading the blind.

Actually, it may be better to make updates than not. The Shib devs
and "regulars" will usually correct anything that is actually wrong.
And the best time to do it is while it is still fresh in your mind.

I recently went looking for a page that I knew existed on the wiki,
and tried several different spots before I finally found it. So I
immediately turned around and edited all the spots I tried first to
include a link to the page. If others were to do likewise when they
encountered difficulties, it will save others (and ourselves!) time
later.

I'm excited about Chad's idea for including more examples in the
process. If we can get a couple of widely-used vendors in there
(such as Google) it could help a lot with understanding for people who
extrapolate best from examples.

%% Christopher A. Bongaarts %% c...@tc.umn.edu %%
%% OIT/OIA Architecture %% http://umn.edu/~cab %%
%% University of Minnesota %% +1 (612) 625-1809 %%

[Michael J. Wheeler]

Chad,

I was not trying to start a flame-war here, I was only trying to point out
my experience as a newbie, and it seems like my experience is not
completely uncommon.

I have infinite respect for you, Scott, and everyone else on the Shibboleth
team. You guys bust your a$$es to come up with an absolutely amazing
project that solves a lot of problems in the .edu space.

I was just noting that the "it's in the docs" doesn't always help us
newbies because there is SO much documentation and there's such a steep
learning curve. I, too, have read through the understanding Shibboleth
section and I'd like to think I have a functional idea of how all the
pieces fit together.

But, when it comes to using Shibboleth with Google Apps, and when Google
doesn't even implement the "standard" correctly, figuring out if the
problem lies with Google or Shibboleth can be a daunting task. And getting
the "it's in the docs so you should know it" response off the mailing list
doesn't help.

Again, I wasn't attempting to start a flame war, and if that's what I did,
I sincerely apologize. I was merely trying to point out to the gurus that
us newbies may not be able to read and digest all the documentation, or
even figure out the context in which it applies. That's where I see the
value in the mailing list. But it makes it difficult when the mailing list
just points us back to the docs.

I wish I could read the documentation from "cover to cover" and immediately
understand it all, but unfortunately I'm not that intelligent.

--
Michael J. Wheeler
Assistant Director, Systems and Networking
Pittsburg State University
Phone: 620-235-4610
E-mail: mwhe...@pittstate.edu

[Scott Cantor]

Christopher A Bongaarts wrote on 2009-08-19:
> I recently went looking for a page that I knew existed on the wiki, and
> tried several different spots before I finally found it. So I
> immediately turned around and edited all the spots I tried first to
> include a link to the page. If others were to do likewise when they
> encountered difficulties, it will save others (and ourselves!) time
> later.

Maybe your case is different, but I don't generally have problems finding
things if I just search for the relevant terms. But I will say that we're
severely underusing tags. I've been trying to add them where I remember to,
but it would be as effective if not moreso to just add some useful tags to
the page you couldn't find.

Like anything in the wiki, the set of tags to use is just self-evolving and
will consolidate over time.

-- Scott