IDP v3.3.x - Help on translation PrincipalConnector => NameIDConsumptionConfiguration

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

IDP v3.3.x - Help on translation PrincipalConnector => NameIDConsumptionConfiguration

Marco Malavolti

Hi to all,

GARR is trying to use a Shibboleth IdP (v3.3.x) as an Attribute Authority to release specific attributes.

For example we desire to release the "isMemberOf" attribute defined as follow in our attribute-resolver.xml (studied for our Grouper instance):

<!-- AttributeDefinition for "isMemberOf" attribute -->
<AttributeDefinition id="isMemberOf" xsi:type="Simple" sourceAttributeID="isMemberOf">
<Dependency ref="isMemberOfDataConnector" />
<DisplayName xml:lang="en">Grouper groups</DisplayName>
<DisplayName xml:lang="it">Gruppi Grouper</DisplayName>
<DisplayDescription xml:lang="en">List of groups retrieved from Grouper</DisplayDescription>
<DisplayDescription xml:lang="it">Elenco dei gruppi ottenuti da Grouper</DisplayDescription>
<AttributeEncoder xsi:type="SAML2String" name="urn:oid:1.2.840.113556.1.666.1" friendlyName="isMemberOf" />
</AttributeDefinition>
<!-- Grouper Database connector -->
<DataConnector xsi:type="RelationalDatabase" id="isMemberOfDataConnector">
<ApplicationManagedConnection jdbcDriver="com.mysql.jdbc.Driver"
jdbcURL="jdbc:mysql://localhost:3306/grouper"
jdbcUserName="###_USER_DB_###"
jdbcPassword="###_SECRET_###" />
<QueryTemplate>
<![CDATA[
SELECT DISTINCT REPLACE(GROUP_NAME, CONCAT('resources:', SUBSTRING_INDEX(SUBSTRING_INDEX('$requestContext.getPeerEntityId()', '//', -1), '/', 1), ':'), '') AS GROUP_NAME
FROM grouper_memberships_lw_v
WHERE subject_id LIKE (SELECT subject_id FROM grouper_members WHERE subject_identifier0 = '$requestContext.principalName')
AND GROUP_NAME LIKE CONCAT('resources:', SUBSTRING_INDEX(SUBSTRING_INDEX('$requestContext.getPeerEntityId()', '//', -1), '/', 1), '%')
AND list_name = 'members'
AND GROUP_NAME NOT LIKE '%:service:%'
]]>
</QueryTemplate>
<Column columnName="GROUP_NAME" attributeID="isMemberOf" />
</DataConnector>


We recognize the user throught its eduPersonPrincipalName($requestContext.principalName) that is sent from the SP (where the user is trying the login) to retrieve additional attributes from our AA. It has been possible thanks the PrincipalConnector:

<!-- ========================================== -->
<!--Deprecated Principal Connectors -->
<!-- ========================================== -->
<PrincipalConnector xsi:type="pc:Direct" id="saml2Direct" nameIDFormat="urn:oasis:names:tc:SAML:2.0:nameid-format:unspecified"/>


As you see, this PrincipalConnector is DEPRECATED and we know that now there is a new way to do what we are doing with it: NameIDConsumptionConfiguration

Unfortunately, I have no idea how can I translate the deprecated PrincipalConnector into the new NameIDConsumptionConfiguration and I need your help to do this and trashing the old stuff.

I hope you can help us to trashing the old and deprecated stuff and, I hope, it will be useful for other people.

Thank you all guys!

-- 
Marco Malavolti
Consortium GARR - Servizio IDEM GARR AAI
Via dei Tizii, 6 - I-00185 (ROMA)
CF: 97284570583 - PI:07577141000
Tel.: 02 6448 2507
Skype: marco.mala

--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]

smime.p7s (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

RE: IDP v3.3.x - Help on translation PrincipalConnector => NameIDConsumptionConfiguration

Rod Widdowson
For a start the Principal Connector is only used when there is a back channel operation in progress.  How does your IdP work when
there is no back channel operation?

I haven't swapped the relying party recognition stuff in recently but I'm reasonably sure that $requestContext.principalName is the
same both back and forwards and is derived from (rather than being) the nameID.

R

--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: IDP v3.3.x - Help on translation PrincipalConnector => NameIDConsumptionConfiguration

Marco Malavolti

Hi Rod and thanks for your help,

We use the backchannel on our IdP/AA with port 8443.

MM


Il 04/05/2018 11:48, Rod Widdowson ha scritto:
For a start the Principal Connector is only used when there is a back channel operation in progress.  How does your IdP work when
there is no back channel operation?

I haven't swapped the relying party recognition stuff in recently but I'm reasonably sure that $requestContext.principalName is the
same both back and forwards and is derived from (rather than being) the nameID.

R


-- 
Marco Malavolti
Consortium GARR - Servizio IDEM GARR AAI
Via dei Tizii, 6 - I-00185 (ROMA)
CF: 97284570583 - PI:07577141000
Tel.: 02 6448 2507
Skype: marco.mala

--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]

smime.p7s (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

RE: IDP v3.3.x - Help on translation PrincipalConnector => NameIDConsumptionConfiguration

Cantor, Scott E.
In reply to this post by Marco Malavolti
> I hope you can help us to trashing the old and deprecated stuff and, I hope, it
> will be useful for other people.

I'll write up an example in the page based on use of EPPN (likely with the use case being "chop the scope off").

-- Scott

--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: IDP v3.3.x - Help on translation PrincipalConnector => NameIDConsumptionConfiguration

Marco Malavolti

Thank you SCOTT!

I hope that my needs are clear....

If not, I'm here.


Best regards,
Marco


Il 04/05/2018 15:33, Cantor, Scott ha scritto:
I hope you can help us to trashing the old and deprecated stuff and, I hope, it
will be useful for other people.
I'll write up an example in the page based on use of EPPN (likely with the use case being "chop the scope off").

-- Scott


-- 
Marco Malavolti
Consortium GARR - Servizio IDEM GARR AAI
Via dei Tizii, 6 - I-00185 (ROMA)
CF: 97284570583 - PI:07577141000
Tel.: 02 6448 2507
Skype: marco.mala

--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]

smime.p7s (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

RE: IDP v3.3.x - Help on translation PrincipalConnector => NameIDConsumptionConfiguration

Cantor, Scott E.
In reply to this post by Marco Malavolti
> Unfortunately, I have no idea how can I translate the deprecated
> PrincipalConnector into the new NameIDConsumptionConfiguration and I need
> your help to do this and trashing the old stuff.

Umm, the examples commented out in the subject-c14n.xml file are literally the exact example you asked for, so I'm not sure what to document further. I'd need a better idea of what's not making sense.

The example shows how to chop a domain off an ID inbound from whatever SPs you enumerate and with whatever Formats you enumerate. It's basically an example of any number of simple PrincipalConnectors all doing a similar thing at once.

Of course, if the mapping process isn't a simple regex transform, that would need more work but having a specific use case for that to document would probably be a better starting point.

-- Scott

--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]