H2 enrich external IdP information with internal attributes
Demin Olivier
Olivier.Demin at generali.be
Tue Jan 29 07:17:56 EST 2013
Scott,
Thanks for your helpful hints. I'll continue on that basis and will come back if I have more questions.
Brgds
Olivier Demin
Head of Front Department/IT Change
Solution Architect
Tel: +32 (0)2 403 8083
Mobile: +32 (0)473 83 10 29
Avenue Louise 149 Mail: olivier.demin at generali.be
B-1050 Bruxelles Site: www.generali.be
Please consider your environmental responsibility before printing this e-mail, thanks for the planet.
-----Original Message-----
From: users-bounces at shibboleth.net [mailto:users-bounces at shibboleth.net] On Behalf Of Cantor, Scott
Sent: mardi 29 janvier 2013 3:50
To: Shib Users
Subject: Re: H2 enrich external IdP information with internal attributes
On 1/28/13 7:33 PM, "Demin Olivier" <Olivier.Demin at generali.be> wrote:
>From what I understood, I need to configure my SP with:
>-
>An SSO profile with the External IdP
>-
>And an AttributeQuery profile with my internal IdP in order to enrich
>the attributes received from the external IdP with internal attributes
>(the internal idp queries my user repository based on the external id
>to retrieve internal attributes)
You can do that with a Shibboleth SP, yes. It's a bit unusual, but it's a straightforward combination of the features it has. Assuming that your internal attribute authority (IdP) has the mappings from the external IdP usernames to your internal data. That's the main thing you have to have to do this with SOAP queries, one of the two IdPs has to know how to crosswalk between the namespaces.
>
>Am I on the right track? If not, is what I need to do possible with
>Shibboleth and how?
>
>Would anybody have some example Shibboleth config files for the SP and
>IdP for similar configuration? Or point me to some documentation that
>would help me realize this? I haven¹t been able to configure this
>until now with the Shibboleth wiki pages.
You have to configure your IdP to support queries based on a username from the other IdP. That usually means a PrincipalConnector of type "Direct", see Accepting the Name Identifier under https://wiki.shibboleth.net/confluence/display/SHIB2/IdPNameIdentifier
You have to define a SAML NameID format to use that will correspond to this piece of data, and then map that via the PrincipalConnector so that it can be turned into a principalName inside the resolver for use in the data connectors. The best thing to use is the unique name of the attribute supplied by the external IdP. If the name it supplies is bogus or not a URI suitable for a NameID Format then you'll have to define something.
The query itself is trivial, you configure something like this in the SP:
<AttributeResolver type="SimpleAggregation" attributeId="user_id"
format="https://example.com/userid">
<Entity>https://example.edu/idp/shibboleth</Entity>
</AttributeResolver>
format is the NameID format to use matching the PrincipalConnector and Entity is the name of your IdP.
-- Scott
--
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net
###########################################<br>GENERALI BELGIUM NV-SA - Verzekeringen-Assurances<br>Louizalaan 149 Avenue Louise - Brussel 1050 Bruxelles<br>Ondernemingsnummer 0403.262.553 Numéro d'entreprise<br>RPR Brussel - RPM Bruxelles<br>###########################################<br>This e-mail and any files transmitted with it are confidential and<br>intended solely for the use of the individual or entity to whom they <br>are addressed. If you have received this e-mail in error please notify <br>the system manager.
More information about the users
mailing list