SAML proxy of IdP to Azure - c14 + requester questions

[Dave Perry]

Thanks Tony

I didn't have an attribute-sourced-subject...xml file in my installation (based on 4.2.1). But just copy/pasting the 6 or 8 lines for it, from the cookbook, caused errors.

Moving to the 4.1 way as you described (including having to delete the file named above), seems to not be picking up the canonicalNameToUseForJoin Id. So it is not able to complete the c14/attribute flow, and the logs are saying 'DataConnector passthroughAttributes produced the following 0 attributes during resolution: []' - even though the AttributeDefinition needed, DataConnector needed, and filter policy needed are there in the appropriate config files.
azureName is definitely being detected according to the logs file.
_________________________________________________

Dave Perry
Application Analyst  |  Innovation & Technology Services

York St John University

Lord Mayor’s Walk, York, YO31 7EX
T: +44(0)1904 876 0000
email at yorksj.ac.uk<mailto:email at yorksj.ac.uk>  |  www.yorksj.ac.uk<http://www.yorksj.ac.uk/>

[cid:659e73dd-a7bf-4b75-af20-75a7d68c5234]

________________________________
From: Cantor, Scott <cantor.2 at osu.edu>
Sent: 17 April 2023 23:56
To: Shib Users <users at shibboleth.net>
Cc: Dave Perry <d.perry1 at yorksj.ac.uk>
Subject: Re: SAML proxy of IdP to Azure - c14 + requester questions

Caution: Please take care when clicking on links or opening attachments in emails that originate from outside of the university. When in doubt, contact the ITS service desk.


> Noting that it says the document hasn't been updated for v4.1+

That's why you should use the documentation itself.

https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fshibboleth.atlassian.net%2Fwiki%2Fspaces%2FIDP4%2Fpages%2F1282539600%2FSAMLAuthnConfiguration&data=05%7C01%7Cd.perry1%40yorksj.ac.uk%7C0ea6c048644442d6fade08db3f96efd6%7C5c8ae38ef85b4309b7ec862815a37aee%7C0%7C0%7C638173689742228698%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=b3EBHYEbsQbIx4OwqRba%2FgFnRoUe2CFxuhzLxUh5hIA%3D&reserved=0<https://shibboleth.atlassian.net/wiki/spaces/IDP4/pages/1282539600/SAMLAuthnConfiguration>

It's covered there.

> When checking the process log, as it checks against each Attribute Filter, it is showing a
> request value of the IdP's entityID.

Yes. The SP in that step is the "IdP" (your IdP). The IdP is Azure. So the requester is you and the issuer is the Azure entityID. That's inbound filtering, and is covered in the documentation.

> I'm not clear why it has seemingly 'lost' the original resource URL requested

The original resource URL is in no way ever known, that's not part of SAML. If your attribute acceptance inbound depends on the identity of the original SP (not the URL), then that is possible to build rules against that via the ProxiedRequester matchers, but generally it doesn't, it's normally just based on the issuer, and there are full set of rules included for that.

-- Scott


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20230417/a1ac8eb9/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Outlook-k1su032u.png
Type: image/png
Size: 12155 bytes
Desc: Outlook-k1su032u.png
URL: <http://shibboleth.net/pipermail/users/attachments/20230417/a1ac8eb9/attachment.png>