IDP compound attribute definition
Bin Han
Bin.Han at concordia.ca
Wed Jan 11 16:13:32 EST 2017
Hello everyone:
Looking for some advices concerning compound attribute definition in IDP V3.
So far we are sending the required attributes to SP (which is developed in house, not the standard Shibboleth SP package), in the default Shibboleth SAML we sent:
<saml2:AttributeStatement>
<saml2:Attribute FriendlyName="client.id"
Name="urn:oid:2.16.840.1.113883.4.642.1"
NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"
>
<saml2:AttributeValue>foo</saml2:AttributeValue>
</saml2:Attribute>
<saml2:Attribute FriendlyName="client.firstname"
Name="urn:oid:2.16.840.1.113883.4.642.2"
NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"
>
<saml2:AttributeValue>bar</saml2:AttributeValue>
</saml2:Attribute>
...
<saml2:AttributeStatement>
However the expected xml schema from our SP supplier is as following:
<saml2:AttributeStatement>
<saml2:Attribute Name="payload" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
<saml2:AttributeValue xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="xs:string"><?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<paymentInformation>
<clientId>1000063192</clientId>
<client>
<firstName>first</firstName>
<lastName>last</lastName>
...
</client>
<service>
<id>100000003132</id>
<amount>100.00</amount>
</service>
</paymentInformation>
</saml2:AttributeValue>
</saml2:Attribute>
</saml2:AttributeStatement>
So my question is, can I define compound attribute in resolver such as:
<client>
<firstname></firstname >
<lastname></lastname >
</client>
Or should I customize the SAML schema somewhere in attribute filter?
It is worth to mention that most of the attributes we are sending to SP are retrieved from a web service built by another internal department through a scripted data connector,
<resolver:AttributeDefinition id="client.firstName" xsi:type="ad:Simple" sourceAttributeID="client_firstName">
<resolver:Dependency ref="ScriptedAttributeConnector_WU" />
...
</resolver:AttributeDefinition>
So I assume static dataconnector cannot be used here.
Thanks,
Bin
-----Original Message-----
From: users [mailto:users-bounces at shibboleth.net] On Behalf Of users-request at shibboleth.net
Sent: January-11-17 2:54 PM
To: users at shibboleth.net
Subject: users Digest, Vol 67, Issue 38
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. AuthnContextClassRef from SSP SP seeming to be ignored
(Wessel, Keith)
2. Re: AuthnContextClassRef from SSP SP seeming to be ignored
(Cantor, Scott)
3. Re: AuthnContextClassRef from SSP SP seeming to be ignored
(Cantor, Scott)
----------------------------------------------------------------------
Message: 1
Date: Wed, 11 Jan 2017 19:40:31 +0000
From: "Wessel, Keith" <kwessel at illinois.edu>
To: "users at shibboleth.net" <users at shibboleth.net>
Subject: AuthnContextClassRef from SSP SP seeming to be ignored
Message-ID: <a06975be29e744a89092062d71085190 at uex135.ad.uillinois.edu>
Content-Type: text/plain; charset="us-ascii"
Hi, all,
Looking for thoughts on how to best debug this or atheory of what I might be doing wrong.
I've got a SimpleSAMLphp SP that will be part of a proxy IdP setup. I'd like it to request our MFA context. It works fine with password authentication, but when I add:
'saml:AuthnContextClassRef' => 'urn:mace:incommon:uiuc.edu:custom'
(No, that's not really the context class ref I'm using; figured the realone didn't need to be posted here) to the SP configuration, I still get through with just password. Requesting the same context from a Shib SP results in me being prompted for MFA.
The SP is definitely including the context class ref in the request. Here's the tail end of the request from the SSP logs:
2017-01-11T13:25:20.576794-06:00 grady-test1 simplesamlphp[7357]: 7 [12cd40567d] <samlp:RequestedAuthnContext>
2017-01-11T13:25:20.576833-06:00 grady-test1 simplesamlphp[7357]: 7 [12cd40567d] <saml:AuthnContextClassRef xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">urn:mace:incommon:uiuc.edu:custom</saml:AuthnContextClassRef>
2017-01-11T13:25:20.576872-06:00 grady-test1 simplesamlphp[7357]: 7 [12cd40567d] </samlp:RequestedAuthnContext>
2017-01-11T13:25:20.576910-06:00 grady-test1 simplesamlphp[7357]: 7 [12cd40567d] </samlp:AuthnRequest>
The audit log from the IdP tells me that the authn context class in the response is, in fact, password and not MFA. I wouldn't expect anything different.
What would be a good starting point for debugging this? What might I turn up logging for first? Or does anyone know of anything about the way that SSP passes such requests through that would cause it not to work with Shib?
Thanks,
Keith
------------------------------
Message: 2
Date: Wed, 11 Jan 2017 19:52:47 +0000
From: "Cantor, Scott" <cantor.2 at osu.edu>
To: Shib Users <users at shibboleth.net>
Subject: Re: AuthnContextClassRef from SSP SP seeming to be ignored
Message-ID: <C777D595-14B2-443A-9166-32C406D60651 at osu.edu>
Content-Type: text/plain; charset="utf-8"
On 1/11/17, 2:40 PM, "users on behalf of Wessel, Keith" <users-bounces at shibboleth.net on behalf of kwessel at illinois.edu> wrote:
> I've got a SimpleSAMLphp SP that will be part of a proxy IdP setup.
> I'd like it to request our MFA context. It works fine with password authentication, but when I add: 'saml:AuthnContextClassRef' => 'urn:mace:incommon:uiuc.edu:custom'
> (No, that's not really the context class ref I'm using; figured the realone didn't need to be posted here)
> to the SP configuration, I still get through with just password.
> Requesting the same context from a Shib SP results in me being prompted for MFA.
My natural assumption would be that the testing methodology is flawed somehow, it would be far easier to assume that the real problem is with the IdP config than jumping to the idea that SSP is requesting it differently, just seems hard to believe.
> The SP is definitely including the context class ref in the request. Here's the tail end of the request from the SSP logs:
That seems to show it only requesting a single context. The only likely explanation I could see would be if it was requesting multiple and one of them hit the password factor. So if not, I don't see how this is possible.
> What would be a good starting point for debugging this? What might I
> turn up logging for first? Or does anyone know of anything about the way that SSP passes such requests through that would cause it not to work with Shib?
I guess comparing a DEBUG log between the two SP cases maybe. Brent has a way of logging/printing the context tree inside the IdP but I haven't used it so I don't know how easy it is to get that into a script step or something like that, I think we talked about wiring that in as a feature people could more readily use but we haven't done that.
The machinery in the IdP is all going to respond to the RequestedPrincipalContext child, that's where the request's rules are going to be reflected. There's no reason that context would be different in these cases. If it were not, then it would be 100% clear the issue here is how you're testing and in what order, and that the other SP would be equally impacted.
-- Scott
------------------------------
Message: 3
Date: Wed, 11 Jan 2017 19:54:20 +0000
From: "Cantor, Scott" <cantor.2 at osu.edu>
To: Shib Users <users at shibboleth.net>
Subject: Re: AuthnContextClassRef from SSP SP seeming to be ignored
Message-ID: <DDC8BCD4-0008-4E12-AFCA-F791F44590C2 at osu.edu>
Content-Type: text/plain; charset="utf-8"
If that's Mike Grady running the test here, and he wants to sanity check it against OSU's IdP, I can provide a context class for that to trigger Duo here. If that doesn't work, you will have my full attention and one end or the other has a bug.
-- Scott
On 1/11/17, 2:52 PM, "users on behalf of Cantor, Scott" <users-bounces at shibboleth.net on behalf of cantor.2 at osu.edu> wrote:
On 1/11/17, 2:40 PM, "users on behalf of Wessel, Keith" <users-bounces at shibboleth.net on behalf of kwessel at illinois.edu> wrote:
> I've got a SimpleSAMLphp SP that will be part of a proxy IdP setup. I'd like it to request our MFA context. It works fine with
> password authentication, but when I add: 'saml:AuthnContextClassRef' => 'urn:mace:incommon:uiuc.edu:custom'
> (No, that's not really the context class ref I'm using; figured the realone didn't need to be posted here)
> to the SP configuration, I still get through with just password. Requesting the same context from a Shib SP results in me
> being prompted for MFA.
My natural assumption would be that the testing methodology is flawed somehow, it would be far easier to assume that the real problem is with the IdP config than jumping to the idea that SSP is requesting it differently, just seems hard to believe.
> The SP is definitely including the context class ref in the request. Here's the tail end of the request from the SSP logs:
That seems to show it only requesting a single context. The only likely explanation I could see would be if it was requesting multiple and one of them hit the password factor. So if not, I don't see how this is possible.
> What would be a good starting point for debugging this? What might I turn up logging for first? Or does anyone know of
> anything about the way that SSP passes such requests through that would cause it not to work with Shib?
I guess comparing a DEBUG log between the two SP cases maybe. Brent has a way of logging/printing the context tree inside the IdP but I haven't used it so I don't know how easy it is to get that into a script step or something like that, I think we talked about wiring that in as a feature people could more readily use but we haven't done that.
The machinery in the IdP is all going to respond to the RequestedPrincipalContext child, that's where the request's rules are going to be reflected. There's no reason that context would be different in these cases. If it were not, then it would be 100% clear the issue here is how you're testing and in what order, and that the other SP would be equally impacted.
-- Scott
--
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net
------------------------------
Subject: Digest Footer
--
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net
------------------------------
End of users Digest, Vol 67, Issue 38
*************************************
More information about the users
mailing list