[Shib-Users] Re: Google Apps SSO

[Rice,Joshua D]

Michael,

    Just recently I ran into the same problem you encountered.  I noticed these lines in my debug log that seemed particularly interesting:

 

20:00:01.624 - DEBUG [edu.internet2.middleware.shibboleth.common.attribute.provider.ShibbolethSAML2AttributeAuthority:225] - Attribute principal was not encoded because no SAML2AttributeEncoder was attached to it.
20:00:01.624 - DEBUG [edu.internet2.middleware.shibboleth.common.attribute.provider.ShibbolethSAML2AttributeAuthority:225] - Attribute transientId was not encoded because no SAML2AttributeEncoder was attached to it.
20:00:01.624 - DEBUG [edu.internet2.middleware.shibboleth.common.attribute.provider.ShibbolethSAML2AttributeAuthority:127] - No attributes remained after encoding and filtering by value, no attribute statement built

Does anyone know if that could have something to do with the problem?  The odd thing is that my attribute resolver for principal does have an encoder statement:

 

    <resolver:AttributeDefinition id="principal" xsi:type="PrincipalName" xmlns="urn:mace:shibboleth:2.0:resolver:ad">
        <resolver:AttributeEncoder xsi:type="SAML2StringNameID"
                                   xmlns="urn:mace:shibboleth:2.0:attribute:encoder"
                                   nameFormat="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified"/>
    </resolver:AttributeDefinition>

 

Unfortunately I'm not sure I'm even barking up the right tree here.

 

Josh Rice

The University of Akron

 

 

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! :)

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

[Scott Cantor]

> The odd thing is that my attribute resolver for principal does have an
encoder
> statement:

But not an encoder for SAML 2.0 Attribute syntax, that's for a NameID.

https://spaces.internet2.edu/display/SHIB2/NameIDAttributes

-- Scott

[Michael J. Wheeler]

Josh,

Your attribute resolver looks good for Google Apps. The problem may be with
your attribute filter. What do you have for releasing the principal and
transientID attributes?

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

> <http://groups.google.com/groups/unlock?_done=/group/shibboleth-users/browse_thread/thread/46f87857661d6588/b4af7273256159e3&msg=f4afaf6152c0f5f6>@hawaii.edu>

[Chad La Joie]

What problem? Certainly nothing in the log message indicates there was
an error.

Rice,Joshua D wrote:
> Michael,
> Just recently I ran into the same problem you encountered. I noticed these lines in my debug log that seemed particularly interesting:
>
> 20:00:01.624 - DEBUG [edu.internet2.middleware.shibboleth.common.attribute.provider.ShibbolethSAML2AttributeAuthority:225] - Attribute principal was not encoded because no SAML2AttributeEncoder was attached to it.
> 20:00:01.624 - DEBUG [edu.internet2.middleware.shibboleth.common.attribute.provider.ShibbolethSAML2AttributeAuthority:225] - Attribute transientId was not encoded because no SAML2AttributeEncoder was attached to it.
> 20:00:01.624 - DEBUG [edu.internet2.middleware.shibboleth.common.attribute.provider.ShibbolethSAML2AttributeAuthority:127] - No attributes remained after encoding and filtering by value, no attribute statement built
> Does anyone know if that could have something to do with the problem? The odd thing is that my attribute resolver for principal does have an encoder statement:
>
> <resolver:AttributeDefinition id="principal" xsi:type="PrincipalName" xmlns="urn:mace:shibboleth:2.0:resolver:ad">
> <resolver:AttributeEncoder xsi:type="SAML2StringNameID"
> xmlns="urn:mace:shibboleth:2.0:attribute:encoder"
> nameFormat="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified"/>
> </resolver:AttributeDefinition>
>
> Unfortunately I'm not sure I'm even barking up the right tree here.
>
> Josh Rice
> The University of Akron

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

[Michael J. Wheeler]

Chad,

I'm guessing it doesn't work and he's trying to figure out why. :)

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

[Rice,Joshua D]

Michael,
You would be right. I think I've gotten around the problem the same way you did, but I agree with you. It seems like there should be a better way.

I guess what I think is that the problem is either in how I think Shibboleth is working, how Google implemented their SAML interface for us. I don't understand why, if we release attributes to Google, those attributes seem to be filtered out. Scott suggested that I don't have the right sort of encoder setup, but trying to figure out what to do about that seems a bit confusing. It appears to me that the right encoder isn't for attributes, but a unique identifier of a different sort. Unfortunately that is where I started to get lost in the documentation and couldn't get enough pieces together in my head to make sense of it all.

Josh Rice
The University of Akron

[Chad La Joie]

Well, the first thing you need is for Google to state clearly what it is
they want, a name identifier or an attribute (I *think* they want name
identifiers). Then I'd recommend reading this [1] which talks about the
similarities and differences between SAML name identifiers and
attributes within Shibboleth. That should hopefully get you to a point
where you can tell which encoder you need to place on the attribute
definition you're using.

I have never used Google Apps so I can't give you explicit directions.
Again, Google has to say what they need. It's always up to the SP to
indicate the information they need and how they expect to get it.
Without that as a starting point there is little you can do. The
chances that you just happen to configure the IdP right without such
information is pretty minimal.

[1] https://spaces.internet2.edu/display/SHIB2/NameIDAttributes

Rice,Joshua D wrote:
> Michael,
> You would be right. I think I've gotten around the problem the same way you did, but I agree with you. It seems like there should be a better way.
>
> I guess what I think is that the problem is either in how I think Shibboleth is working, how Google implemented their SAML interface for us. I don't understand why, if we release attributes to Google, those attributes seem to be filtered out. Scott suggested that I don't have the right sort of encoder setup, but trying to figure out what to do about that seems a bit confusing. It appears to me that the right encoder isn't for attributes, but a unique identifier of a different sort. Unfortunately that is where I started to get lost in the documentation and couldn't get enough pieces together in my head to make sense of it all.
>
> Josh Rice
> The University of Akron
>
> -----Original Message-----
> From: Michael J. Wheeler [mailto:mwhe...@pittstate.edu]
> Sent: Wednesday, September 23, 2009 12:08 PM
> To: shibbole...@internet2.edu
> Subject: Re: [Shib-Users] Re: Google Apps SSO
>
> Chad,
>
> I'm guessing it doesn't work and he's trying to figure out why. :)
>

--

[Scott Cantor]

Rice,Joshua D wrote on 2009-09-23:
> Michael, You would be right. I think I've gotten around the problem
> the same way you did, but I agree with you. It seems like there should
> be a better way.

SAML Attributes and NameIDs are not the same thing to many SPs on the wire, Google being one of them, and there's a specific mechanism documented to generate each one once you have a resolved, released internal attribute to use.

> I guess what I think is that the problem is either in how I think
> Shibboleth is working, how Google implemented their SAML interface for us.
> I don't understand why, if we release attributes to Google, those attributes
> seem to be filtered out. Scott suggested that I don't have the right sort
> of encoder setup, but trying to figure out what to do about that seems a bit
> confusing.

What I said is that you are encoding data as SAML Attributes, and I suspect from past complaints that Google requires a SAML NameID. Then I pointed at the explanation of the difference. If you want to generate a NameID, there's a different encoder to use. The "Attribute" in the AttributeEncoder construct is not referring to SAML Attributes, but to the internal resolver attributes. I wish we'd used a different name to some extent, but there aren't a lot of good words to use.

> It appears to me that the right encoder isn't for attributes,
> but a unique identifier of a different sort.

Unique isn't the issue. It's a NameID, that's the issue.

The encoder you probably want is here:
https://spaces.internet2.edu/display/SHIB2/SAML2StringNameIDEncoder

What I just noticed is that the set of inbound links to that topic is seriously lacking. I'll see if I can do something about it, but the general issue is that we don't really favor using the NameID the way Google does, and the documentation isn't geared to their choice.

-- Scott

[Michael J. Wheeler]

I agree with Scott with regards to Google's implementation of NameID vs an
Attribute. After having implemented a few more SP's on campus with our IdP,
Google seems to be in the minority as to how they want their data.

That also seems to be the major place where newbies (like me) setting up
Shib + Google Apps run into trouble. It would be so much easier if one
didn't have to filter out the transientID and just pass the user identifier
to Google as an attribute.

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

[Scott Cantor]

Michael J. Wheeler wrote on 2009-09-23:
> I agree with Scott with regards to Google's implementation of NameID vs an
> Attribute. After having implemented a few more SP's on campus with our IdP,
> Google seems to be in the minority as to how they want their data.

Well, use Shib a lot and of course you're subject to selection bias on that, but the reason we do that is that using NameIDs other than transient and persistent is essentially using underspecified semantics that don't serve anybody very well.

> That also seems to be the major place where newbies (like me) setting up
> Shib + Google Apps run into trouble. It would be so much easier if one
> didn't have to filter out the transientID and just pass the user identifier
> to Google as an attribute.

So, please take a look at this:

https://spaces.internet2.edu/display/SHIB2/IdPCustomNameIdentifier

Does that match what you had to do, and address the confusion?

It's now linked, with attendant warnings about what breaks if you do this, from the IdPNameIdentifier topic.

-- Scott

[Jim Fox]

Will has some notes on google and shib that include configuration
information:

https://shibboleth.usc.edu/docs/google-apps/

Jim

On Wed, 23 Sep 2009, Scott Cantor wrote:

> Date: Wed, 23 Sep 2009 11:11:11 -0700
> From: Scott Cantor <cant...@osu.edu>
> To: "shibbole...@internet2.edu" <shibbole...@internet2.edu>
> Reply-To: "shibbole...@internet2.edu" <shibbole...@internet2.edu>
> Subject: RE: [Shib-Users] Re: Google Apps SSO

[Michael J. Wheeler]

Jim,

I referenced that document several times when working through Google Apps +
Shib.

But, that document only "shows" you how to set it up. It doesn't do a very
good job of explaining the meaning of everything you're doing. It's more of
a "copy/paste this" quick-start guide.

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

[Michael J. Wheeler]

Scott,

My problems weren't with defining the attribute, my problems were with
releasing it to Google.

TransientID seems to be the "preferred" NameID sent to the SP. So, in order
to get something else in that space, you need to exclude that SP in the
transientID's attribute filter. I know that's how Shib works, but it just
feels "backwards" to me.

It seems to me that it would be "nicer" if transientID were only sent if
there was no other NameID encoded attribute to send. This would make
transientID more of a "default" instead of a "preference".

I'm not sure what the feasibility is of implementing this, or even if it's
forbidden in the SAML spec; I'm merely asking as an end user of Shib.

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

[Scott Cantor]

Michael J. Wheeler wrote on 2009-09-23:
> TransientID seems to be the "preferred" NameID sent to the SP. So, in order
> to get something else in that space, you need to exclude that SP in the
> transientID's attribute filter. I know that's how Shib works, but it just
> feels "backwards" to me.

I don't think that's true, though. I believe it's random (not really, but unspecified at least), not based on any preference for one type over another. I also believe if you have metadata from google saying "we require this format", or a request demanding it, you'd get the right result, barring bugs of course. (I think one was identified around that recently.)

> It seems to me that it would be "nicer" if transientID were only sent if
> there was no other NameID encoded attribute to send. This would make
> transientID more of a "default" instead of a "preference".

There's nothing special to the code about transient though. It's just a format, same as any other.

> I'm not sure what the feasibility is of implementing this, or even if it's
> forbidden in the SAML spec; I'm merely asking as an end user of Shib.

I don't think there's any sensible outcome if you don't request it, don't have SP metadata documenting what it wants, and define multiple source attributes that can be turned into a NameID.

-- Scott

[Scott Cantor]

Scott Cantor wrote on 2009-09-23:
> Michael J. Wheeler wrote on 2009-09-23:
>> I'm not sure what the feasibility is of implementing this, or even if it's
>> forbidden in the SAML spec; I'm merely asking as an end user of Shib.
>

> I don't think there's any sensible outcome if you don't request it, don't
> have SP metadata documenting what it wants, and define multiple source
> attributes that can be turned into a NameID.

One thought that doesn't seem utterly silly, which you can file a request for, is perhaps a setting for the NameID encoder(s) that identifies the data as "default only", to get the semantic you were suggesting. Only gets used if some other encoder without the property isn't available.

-- Scott

[Chad La Joie]

There is already a feature request, by Nate to allow a configured
precedence of NameID formats.

--

[Chad La Joie]

Scott Cantor wrote:
> Michael J. Wheeler wrote on 2009-09-23:
>> TransientID seems to be the "preferred" NameID sent to the SP. So,
>> in order to get something else in that space, you need to exclude
>> that SP in the transientID's attribute filter. I know that's how
>> Shib works, but it just feels "backwards" to me.
>
> I don't think that's true, though. I believe it's random (not really,
> but unspecified at least), not based on any preference for one type
> over another. I also believe if you have metadata from google saying
> "we require this format", or a request demanding it, you'd get the
> right result, barring bugs of course. (I think one was identified
> around that recently.)

No bugs that I can think of regarding this specifically. The NameID
docs in the wiki explain how the attribute used is chosen. There's a
formula to try and whittle down a possible set of choices into a single
choice. If the result of that process is still a collection then it
essentially chooses one at random.

[Scott Cantor]

Chad La Joie wrote on 2009-09-23:
> No bugs that I can think of regarding this specifically. The NameID
> docs in the wiki explain how the attribute used is chosen. There's a
> formula to try and whittle down a possible set of choices into a single
> choice. If the result of that process is still a collection then it
> essentially chooses one at random.

Here's the bug:
https://bugs.internet2.edu/jira/browse/SIDP-342

The best way to get the IdP to behave predictably is with SP metadata, but the bug makes that tricky at the moment.

-- Scott

[Roberto Ullfig]

Michael J. Wheeler wrote:
> I agree with Scott with regards to Google's implementation of NameID
> vs an Attribute. After having implemented a few more SP's on campus
> with our IdP, Google seems to be in the minority as to how they want
> their data.
>
> That also seems to be the major place where newbies (like me) setting
> up Shib + Google Apps run into trouble. It would be so much easier if
> one didn't have to filter out the transientID and just pass the user
> identifier to Google as an attribute.
>

To filter out transientID to google I originally added this:

<AttributeFilterPolicy id="releaseTransientIdToAnyone">
<PolicyRequirementRule xsi:type="basic:NOT">
<basic:Rule xsi:type="basic:AttributeRequesterString"

value="google.com" />

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

However, what if another SP is discovered to act like google? NOT only
takes one Rule. How can I create a simple filter to do this? Right now,
I've explicitly released transientID in every other SP's policy.

--
Roberto Ullfig
Systems Programmer - ACCC

[Scott Cantor]

Roberto Ullfig wrote on 2009-10-02:
> However, what if another SP is discovered to act like google? NOT only
> takes one Rule. How can I create a simple filter to do this? Right now,
> I've explicitly released transientID in every other SP's policy.

Create an OR rule around the SPs that are in the "google" bucket?

-- Scott

[Chad La Joie]

Actually what I would do is change the rule a bit to:

<AttributeFilterPolicy id="noTransientIdForGoogle">
<PolicyRequirementRule xsi:type="basic:AttributeRequesterString"
values="google.com" />

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

Note the use of the DenyValueRule. So, in stead of saying "Send this
anyone but Google" you're saying "Don't send this to Google". By doing
it this way you can ensure that if you ever write another policy that
would cause the attribute to be released to Google that this rule will
still make sure it's never sent (explicit deny *always* wins).

And, as Scott said, if you ever need to list more than one SP you can
always use an OR rule like:

<PolicyRequirementRule xsi:type"basic:OR">
<Rule xsi:type="basic:AttributeRequesterString" values="google.com" />

<Rule xsi:type="basic:AttributeRequesterString"

values="http://example.org" />
</PolicyRequirementRule>

--