OneID Login for Shibboleth

William Lowe will at gluu.org
Fri Mar 29 15:35:51 EDT 2013 

Shib Users,

Gluu has recently integrated OneID, see Press Release at:  http://goo.gl/s9gmW

In combination with the Shibboleth OX Login Handler (see release at: http://goo.gl/VbXvQ), you can now use OneID to login to SAML websites.

The login handler can be found in our public SVN:  https://svn.gluu.info/repository/openxdi/oxAuth/ShibIdpClient  

If you have any questions, you can find our mailing lists at:
http://ox.gluu.org/doku.php?id=resources:mailing_lists


Thanks all!
Will


On Mar 26, 2013, at 11:00 AM, users-request at shibboleth.net wrote:

> Send users mailing list submissions to
> 	users at shibboleth.net
> 
> To subscribe or unsubscribe via the World Wide Web, visit
> 	http://shibboleth.net/mailman/listinfo/users
> or, via email, send a message with subject or body 'help' to
> 	users-request at shibboleth.net
> 
> You can reach the person managing the list at
> 	users-owner at shibboleth.net
> 
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of users digest..."
> 
> 
> Today's Topics:
> 
>   1. Re: Using Metadata in my App (Cantor, Scott)
>   2. Re: Using Metadata in my App (Tom Scavo)
>   3. Re: Using Metadata in my App (Cantor, Scott)
>   4. Re: Using Metadata in my App (Andy Bennett)
>   5. Re: Using Metadata in my App (Cantor, Scott)
> 
> 
> ----------------------------------------------------------------------
> 
> Message: 1
> Date: Tue, 26 Mar 2013 14:46:41 +0000
> From: "Cantor, Scott" <cantor.2 at osu.edu>
> Subject: Re: Using Metadata in my App
> To: Shib Users <users at shibboleth.net>
> Message-ID:
> 	<BA63CEAE152A7742B854C678D94913836C766850 at CIO-KRC-D1MBX01.osuad.osu.edu>
> 	
> Content-Type: text/plain; charset="us-ascii"
> 
> On 3/26/13 8:20 AM, "Andy Bennett" <andyjpb at knodium.com> wrote:
> 
>> At the moment I get Shib-Identity-Provider which is a URI and either
>> targeted-id which is <letters>@<scope> or persistent-id which is
>> <IdP-URI>!<SP-URI>!<letters>.
> 
> It's whatever you choose to serialize it into with the software via the
> decoder rule. The underlying data is a SAML NameID element in XML with a
> three part structure, value, SP qualifier, and IdP qualifier.
> 
> The first thing you probably need to do is read this:
> https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPTargetedID
> 
> That explains why there are different syntaxes floating around this and
> what "targeted-id" is (a legacy name for a broken syntax that was
> accidentally adopted).
> 
> None of what you're talking about is eduPersonPrincipalName (responding to
> Tom). Different attribute with different properties entirely.
> 
>> Shib-Identity-Provider seems to equal <IdP-URI>. Is this always the
>> case?
> 
> In practice. Not in terms of the definition of SAML persistent IDs, no.
> 
>> If an IdP changes their entityID will the value of
>> Shib-Identity-Provider change? Will I still get the same persistent-id
>> for that individual? What about targeted-id?
> 
> The value is the opaque part. The qualifiers are the entityIDs. If those
> change, the qualifiers usually change. How that affects your application
> depends on what you do with the data. You might have to rekey, yes.
> 
> And targeted-id is broken, by definition. You can read the page I pointed
> to and see how to avoid ever seeing it.
> 
>> I find it quite challenging to work through the attribute-map.xml and
>> get a good idea of what will actually end up in my FCGI Variables.
> 
> I can't really respond unless I know what it is you're confused about in
> the file. The most confusing thing is the nonsense around persistent and
> targeted IDs.
> 
>> When a user logs in I look up or create the IdP entry based on
>> Shib-Identity-Provider. This entry tells me whether we like to use
>> targeted-id or persistent-id as the key for these users.
> 
> You may not need to do that if you decode the broken form into a form that
> looks the same as the non-broken form.
> 
>> This is similar to the case my original eMail was trying to target. I
>> currently have a bunch of IdP entries in my database and I want to
>> create a bunch of "Organisation" entries and then associate them with
> 
> That's a perfectly fine thing to want, but neither the entityID nor
> anything that's in SAML metadata is an organizational identifier. The
> history of such things is that we have no standard for such a thing,
> because every application tends to have its own views of what it's trying
> to identify. There are many, many schemas for identifying organizations,
> but they don't span applications.
> 
> I think, personally, that federation creates an opportunity for revisiting
> that question because so many different applications rely on this common
> infrastructure. But we haven't done it, and even if we did, no other
> verticals would probably follow us, which puts the SPs in the same
> situation, no common standard.
> 
> -- Scott
> 
> 
> 
> 
> ------------------------------
> 
> Message: 2
> Date: Tue, 26 Mar 2013 10:47:56 -0400
> From: Tom Scavo <trscavo at gmail.com>
> Subject: Re: Using Metadata in my App
> To: Andy Bennett <andyjpb at knodium.com>
> Cc: Shib Users <users at shibboleth.net>
> Message-ID:
> 	<CAEtu=dOC3mtsHZJahiGfWGpeNXU-==r5jNcJWUy1=Vhc0TXd3w at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
> 
> On Tue, Mar 26, 2013 at 10:23 AM, Andy Bennett <andyjpb at knodium.com> wrote:
>> 
>> Some IdPs send me an opaque targeted-id, some send an opaque
>> persistent-id triple and some send a less opaque eppn plus and opaque
>> targeted-id.
> 
> Well, there's a (conceptual) problem here since "opaque targeted-id"
> and "opaque persistent-id triple" are almost certainly the same thing.
> 
>>    <!-- Second, an alternate decoder that will decode the incorrect
>> form into the newer form. -->
>>    <Attribute name="urn:mace:dir:attribute-def:eduPersonTargetedID"
>> id="persistent-id">
>>        <AttributeDecoder xsi:type="NameIDFromScopedAttributeDecoder"
>> formatter="$NameQualifier!$SPNameQualifier!$Name" defaultQua
>> lifiers="true"/>
>>    </Attribute>
> 
> This is the pre-SAML2 form of ePTID.
> 
>>    <!-- Third, the new version (note the OID-style name): -->
>>    <Attribute name="urn:oid:1.3.6.1.4.1.5923.1.1.1.10" id="persistent-id">
>>        <AttributeDecoder xsi:type="NameIDAttributeDecoder"
>> formatter="$NameQualifier!$SPNameQualifier!$Name" defaultQualifiers="t
>> rue"/>
>>    </Attribute>
> 
> This is the SAML2 form of ePTID.
> 
>>    <!-- Fourth, the SAML 2.0 NameID Format: -->
>>    <Attribute
>> name="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent"
>> id="persistent-id">
>>        <AttributeDecoder xsi:type="NameIDAttributeDecoder"
>> formatter="$NameQualifier!$SPNameQualifier!$Name" defaultQualifiers="t
>> rue"/>
>>    </Attribute>
> 
> This is the SAML2 Persistent NameID, which is 100% equivalent to the
> SAML2 form of ePTID.
> 
>> I'm not using this one:
>> -----
>>    <!-- First, the deprecated/incorrect version, decoded as a scoped
>> string: -->
>>    <Attribute name="urn:mace:dir:attribute-def:eduPersonTargetedID"
>> id="targeted-id">
>>        <AttributeDecoder xsi:type="ScopedAttributeDecoder"/>
>>        <!-- <AttributeDecoder
>> xsi:type="NameIDFromScopedAttributeDecoder"
>> formatter="$NameQualifier!$SPNameQualifier!$Name" defau
>> ltQualifiers="true"/> -->
>>    </Attribute>
>> -----
> 
> I don't see how that's different than the first one above. Someone
> else more knowledgeable about the Shib SP will have to review.
> 
>>> I think you mean ePPN, in which case, yes, ePPN is globally unique.
>> 
>> ...but I don't get access to the raw ePPN from the SAML exchange. I just
>> get some decoded value that involves the entityIDs from "various"
>> places. It's not clear to me whether those entityIDs come from the
>> configuration (shibboleth2.xml for SP-ID, federation XML for IdP-ID) or
>> from the SAML exchange / IdP database backend.
> 
> All I can say for sure is the values supplied to the application do
> NOT come from metadata. They are asserted by the IdP just-in-time.
> 
>>>> What about targeted-id?
>>> 
>>> Technically, no, since ePTID is a triple, one component of which is
>>> the IdP's entityID. If the ePTID value was computed correctly by the
>>> IdP to being with, you would still obtain that same value after their
>>> entityID had changed.
>> 
>> I'm confused. How is that different than from persistent-id? Surely
>> anything involving the entityID will change?
> 
> Yes, I agree, there's confusion :-)
> 
>>> Your goal is laudable but unfortunately the typical SAML metadata file
>>> is not up to the task. For an interesting counterexample, see the
>>> SWITCH metadata:
>>> 
>>> http://metadata.aai.switch.ch/metadata.switchaai.xml
>>> 
>>> Notice the value of the OrganizationName element in each case.
>>> Brilliant, eh? :-)
>> 
>> That looks interesting. The OrganizationName seems to be terse but
>> potentially helpful and then they supply human readable names in a
>> number of languages in the OrganizationDisplayName attribute.
>> It looks like they keep OrganizationName the same for multiple IdPs and
>> SPs from the same organisation. Who knows if they guarantee it.
> 
> The SWITCH folks frequent this list so someone will respond, I'm sure.
> 
> Cheers,
> Tom
> 
> 
> ------------------------------
> 
> Message: 3
> Date: Tue, 26 Mar 2013 14:54:21 +0000
> From: "Cantor, Scott" <cantor.2 at osu.edu>
> Subject: Re: Using Metadata in my App
> To: Shib Users <users at shibboleth.net>, Andy Bennett
> 	<andyjpb at knodium.com>
> Message-ID:
> 	<BA63CEAE152A7742B854C678D94913836C7668B4 at CIO-KRC-D1MBX01.osuad.osu.edu>
> 	
> Content-Type: text/plain; charset="us-ascii"
> 
> On 3/26/13 10:47 AM, "Tom Scavo" <trscavo at gmail.com> wrote:
>> 
>> I don't see how that's different than the first one above. Someone
>> else more knowledgeable about the Shib SP will have to review.
> 
> https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPTargetedID
> 
>> All I can say for sure is the values supplied to the application do
>> NOT come from metadata. They are asserted by the IdP just-in-time.
> 
> They're a mix. SAML allowed qualifiers in NameIDs to be defaulted based on
> context. If they're not sent, they can be defaulted into existence based
> on the identities of the issuer and the recipient. The former comes from
> the SAML response (and by design is what's in the metadata), the latter
> comes from the SP configuration.
> 
> -- Scott
> 
> 
> 
> 
> ------------------------------
> 
> Message: 4
> Date: Tue, 26 Mar 2013 15:07:45 +0000
> From: Andy Bennett <andyjpb at knodium.com>
> Subject: Re: Using Metadata in my App
> To: Shib Users <users at shibboleth.net>
> Message-ID: <5151B9C1.7050604 at knodium.com>
> Content-Type: text/plain; charset="ISO-8859-1"
> 
> Hi,
> 
>> It's whatever you choose to serialize it into with the software via the
>> decoder rule. The underlying data is a SAML NameID element in XML with a
>> three part structure, value, SP qualifier, and IdP qualifier.
>> 
>> The first thing you probably need to do is read this:
>> https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPTargetedID
>> 
>> That explains why there are different syntaxes floating around this and
>> what "targeted-id" is (a legacy name for a broken syntax that was
>> accidentally adopted).
> 
> Ah yes. I remember reading that way back at the beginning when I knew
> even less than I do now. ;-) It was worth another read tho'. Thanks.
> 
> I set up the decoders thusly in attribute-map.xml:
> 
> -----
>    <!-- First, the deprecated/incorrect version, decoded as a scoped
> string: -->
>    <Attribute name="urn:mace:dir:attribute-def:eduPersonTargetedID"
> id="targeted-id">
>        <AttributeDecoder xsi:type="ScopedAttributeDecoder"/>
>        <!-- <AttributeDecoder
> xsi:type="NameIDFromScopedAttributeDecoder"
> formatter="$NameQualifier!$SPNameQualifier!$Name" defau
> ltQualifiers="true"/> -->
>    </Attribute>
> 
>    <!-- Second, an alternate decoder that will decode the incorrect
> form into the newer form. -->
>    <Attribute name="urn:mace:dir:attribute-def:eduPersonTargetedID"
> id="persistent-id">
>        <AttributeDecoder xsi:type="NameIDFromScopedAttributeDecoder"
> formatter="$NameQualifier!$SPNameQualifier!$Name" defaultQua
> lifiers="true"/>
>    </Attribute>
> 
>    <!-- Third, the new version (note the OID-style name): -->
>    <Attribute name="urn:oid:1.3.6.1.4.1.5923.1.1.1.10" id="persistent-id">
>        <AttributeDecoder xsi:type="NameIDAttributeDecoder"
> formatter="$NameQualifier!$SPNameQualifier!$Name" defaultQualifiers="t
> rue"/>
>    </Attribute>
> 
>    <!-- Fourth, the SAML 2.0 NameID Format: -->
>    <Attribute
> name="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent"
> id="persistent-id">
>        <AttributeDecoder xsi:type="NameIDAttributeDecoder"
> formatter="$NameQualifier!$SPNameQualifier!$Name" defaultQualifiers="t
> rue"/>
>    </Attribute>
> -----
> 
> ...and I still seem to get some IdPs who's auth comes thru with old
> style targeted-id and no persistent-id. I wanted to get both variables
> when IdPs were sending the old style and I was transforming it into the
> new style in the SP. The intention was to assert that the value parts
> were equal and then migrate.
> 
> 
> 
>> That's a perfectly fine thing to want, but neither the entityID nor
>> anything that's in SAML metadata is an organizational identifier. The
>> history of such things is that we have no standard for such a thing,
>> because every application tends to have its own views of what it's trying
>> to identify. There are many, many schemas for identifying organizations,
>> but they don't span applications.
>> 
>> I think, personally, that federation creates an opportunity for revisiting
>> that question because so many different applications rely on this common
>> infrastructure. But we haven't done it, and even if we did, no other
>> verticals would probably follow us, which puts the SPs in the same
>> situation, no common standard.
> 
> Thanks for the tips. It looks like there are lengths that I can go to
> that will allow me to reap some benefit from the data in my particular
> Federation but there are no Silver Bullets.
> 
> 
> 
> Thanks!
> 
> 
> 
> 
> 
> Regards,
> @ndy
> 
> -- 
> andyjpb at knodium.com
> http://www.knodium.com/
> 
> 
> 
> 
> ------------------------------
> 
> Message: 5
> Date: Tue, 26 Mar 2013 15:50:04 +0000
> From: "Cantor, Scott" <cantor.2 at osu.edu>
> Subject: Re: Using Metadata in my App
> To: Andy Bennett <andyjpb at knodium.com>, Shib Users
> 	<users at shibboleth.net>
> Message-ID:
> 	<BA63CEAE152A7742B854C678D94913836C7669BD at CIO-KRC-D1MBX01.osuad.osu.edu>
> 	
> Content-Type: text/plain; charset="us-ascii"
> 
> On 3/26/13 11:07 AM, "Andy Bennett" <andyjpb at knodium.com> wrote:
> 
>> I set up the decoders thusly in attribute-map.xml:
>> 
>> -----
>>   <!-- First, the deprecated/incorrect version, decoded as a scoped
>> string: -->
>>   <Attribute name="urn:mace:dir:attribute-def:eduPersonTargetedID"
>> id="targeted-id">
>>       <AttributeDecoder xsi:type="ScopedAttributeDecoder"/>
> 
> Right there you are choosing to keep processing the broken form.
> 
>> ...and I still seem to get some IdPs who's auth comes thru with old
>> style targeted-id and no persistent-id.
> 
> Yes, that would follow.
> 
>> I wanted to get both variables
>> when IdPs were sending the old style and I was transforming it into the
>> new style in the SP. The intention was to assert that the value parts
>> were equal and then migrate.
> 
> Ah. No, it can't do that. The purpose of the new decoder was so you can
> rekey as part of a migration and then switch the decoders. It can't deal
> with a case where you get two different attributes with different values.
> 
> If you want both attributes, then the way you're doing it is the way you
> would do it.
> 
> -- Scott
> 
> 
> 
> 
> ------------------------------
> 
> --
> To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net
> 
> End of users Digest, Vol 21, Issue 81
> *************************************

----
William Lowe
http://linkedin.com/in/whaven
http://gluu.org
o: (925) 470-2230
m: (925) 389-7426 



-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://shibboleth.net/pipermail/users/attachments/20130329/f36218f1/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gluu_logo_small.png
Type: image/png
Size: 7986 bytes
Desc: not available
Url : http://shibboleth.net/pipermail/users/attachments/20130329/f36218f1/attachment-0001.png

More information about the users mailing list