Skip to Content.

edugain-discuss - Re: [eduGAIN-discuss] Use of Azure Active Directory in eduGain

edugain-discuss AT lists.geant.org

Subject: An open discussion list for topics related to the eduGAIN interfederation service.

List archive


Re: [eduGAIN-discuss] Use of Azure Active Directory in eduGain


Chronological Thread 
  • From: Terry Smith <t.smith AT aaf.edu.au>
  • To: "Chan, Toby [ITS]" <toby.chan AT polyu.edu.hk>
  • Cc: "edugain-discuss AT lists.geant.org" <edugain-discuss AT lists.geant.org>
  • Subject: Re: [eduGAIN-discuss] Use of Azure Active Directory in eduGain
  • Date: Wed, 7 Apr 2021 13:40:13 +1000

Hi Toby,

We have one IdP, Western Sydney University (click here to see) that is using a Shibboleth IdP with proxying too two AZURE tenants. The user first sees the IdPs discovery that provides a selection between Staff and Student. Once selected the user is sent to the appropriate AZURE tenant to login. The Shibboleth IdP then takes care of the rest of the federation integration.

It's a reasonably clean solution that has been accepted by the user community at the university.

Thanks,
Terry.

Terry Smith | Head of Support | Australian Access Federation Ltd
Mob:  0414 692 424 Email t.smith AT aaf.edu.au  ORCIDorcid.org/0000-0001-5971-4735
Mail: Level 21 179 Turbot Street | Brisbane QLD 4000 | Australia
 


On Wed, Apr 7, 2021 at 12:33 PM Chan, Toby [ITS] <toby.chan AT polyu.edu.hk> wrote:
Hi Chris,

Thanks! This is a useful knowledge base for us.

Though it may be a little bit off topic. I wonder if any others have deployed 2 separate Azure tenants (one for staff and one for students) for their users? This has been headache to me for years as users didn't collaborate as smooth as they were within the same tenant. I was also unable to fully utilize AAD for in-cloud authentication.   Local MS support gave up and declare as known issue.

Toby



From: edugain-discuss-request AT lists.geant.org on behalf of Chris Phillips
Sent: Wednesday, April 07, 2021 12:08 AM
To: Daniel Muscat; edugain-sg AT lists.geant.org; edugain-discuss AT lists.geant.org
Subject: Re: [eduGAIN-discuss] Use of Azure Active Directory in eduGain

Hi Daniel and others..

We have a number of sites using Azure AD as their backend authenticator only proxied using the Shibboleth IdP v4 as their IdP. Other sites in other federations have reached out on the topic as well as we documented it on the Shibboleth Knowledge Base here [1] for all to use.

Proxying offers us a clear demarcation point and place to exert control for the features we want in an R&E federation IdP at the pace we want which is much faster in most cases.

Other proxy stories can be done with R&E tech like SATOSA and SimpleSAMLPHP. We ourselves use Shib, SATOSA, and SSPHP  in our own solutions for different reasons with the Shibboleth Proxy story being the one recommend first followed by SATOSA and SSPHP. The biggest challenge of anything is knowledge in the field at the institutions and understanding the real problem they are trying to solve. 

We also support ADFS with ADFSToolkit on prem connected to Azure AD which is a common pathway for sites to co-habitate with Azure AD. The biggest draw for that: existing knowledge, infrastructure already deployed, and access to Azure MFA. This is why we've invested in the ADFSToolkit (now at version 2)[2] so we can get sites to REFEDS MFA capable levels on this technology as well.

Included below is the laundry list of Azure AD challenges to help describe why a proxy is needed.

Questions and comments welcome as always and happy to share our experiences so far..

Chris.


Azure AD challenges to being an R&E IdP on its own:
- cannot validate an aggregate with a federation's Signing Key
- cannot handle an aggregate  -- it can only do bi-lateral SAML and not Multi-lateral SAML
- has a limit of 1000 RPs per tenant
- cannot support MDQ
- cannot do entity categories management
- cannot properly support and respond to REFEDS MFA and SFA profiles as triggered by SAML  RPs
- cannot properly contain eduPerson or ShacPerson schema elements in Azure AD without significant schema manipulation to extendedAttributes##[1-13]
- cannot handle custom multi-valued attributes in azure AD consistently (or sometimes at all!)[3][4]
- cannot generate eduPersonTargetedID
- cannot generate scripted attributes with same level of fidelity as other solutions






[1] https://wiki.shibboleth.net/confluence/display/KB/Using+SAML+Proxying+in+the+Shibboleth+IdP+to+connect+with+Azure+AD
[2] https://github.com/fedtools/adfstoolkit
[3] https://docs.microsoft.com/en-us/azure/active-directory/app-provisioning/customize-application-attributes
(Custom attributes can't be referential attributes, multi-value or complex-typed attributes. Custom multi-value and complex-typed extension attributes are currently supported only for applications in the gallery. )
[4] https://docs.microsoft.com/en-us/azure/active-directory/hybrid/how-to-connect-sync-feature-directory-extensions



On 2021-04-06, 9:32 AM, "edugain-discuss-request AT lists.geant.org on behalf of Daniel Muscat" <edugain-discuss-request AT lists.geant.org on behalf of daniel.muscat AT um.edu.mt> wrote:

    Dear all,
      We have a prospective member that will probably need to integrate a
    SAML IDP based on the Azure Active Directory. I am wondering if
    anybody can share any experience on the Azure Active Directory as an
    IDP used to authenticate for SPs on eduGain, in particular inAcademia.

    --
    Regards
    Daniel


Disclaimer:

This message (including any attachments) contains confidential information intended for a specific individual and purpose. If you are not the intended recipient, you should delete this message and notify the sender and The Hong Kong Polytechnic University (the University) immediately. Any disclosure, copying, or distribution of this message, or the taking of any action based on it, is strictly prohibited and may be unlawful.

The University specifically denies any responsibility for the accuracy or quality of information obtained through University E-mail Facilities. Any views and opinions expressed are only those of the author(s) and do not necessarily represent those of the University and the University accepts no liability whatsoever for any losses or damages incurred or caused to any party as a result of the use of such information.




Archive powered by MHonArc 2.6.19.

Top of Page