globus-connect-server oidc register with AzureAD

[Ümit Seren]

Hi, 

we are training to register our AzureAD Identity Provider as an OIDC server for our globus v5 server. 
For this we created an Application Registration in our Azure Tenant and provided all the relevant information (discovery URL, client id and secret).
However the register call returns following error message:

Error registering IdP: Error registering FQDN with Globus Auth: 403 ('POST', 'https://auth.globus.org/v2/api/clients/****/fqdns', 'Basic', 403, 'FORBIDDEN', 'client_id must be in domain txt record', '******'). Please check that a DNS TXT record exists at login.microsoftonline.com with value '*****'.
Error while creating OIDC endpoint: 1

Obviously we can not create the DNS TXT record in the Microsoft domain.
Is there a way to integrate globus server with an identity provider in the cloud such as AzureAD or this only supported for on-prem IDPs ? 

The only possible solution we found was to register an Alternative Identity Provider (https://www.youtube.com/watch?v=CJ_RHl0PPQQ) but we would like to avoid that.

 

[Josh Bryan]

Umit,

Part of the Globus security model around registering your own OIDC server is to verify that it is being hosted from a domain you own.  This is obviously challenging with the default Azure AD configuration since it will serve endpoints from login.microsoftonline.com.  However, Microsoft does support hosting your AD directory on a custom domain.  You can read more about that here.  You are correct that currently the other option Globus supports would be to register an Alternative Identity Provider.  We have had discussions around other ways to verify ownership and operation of OIDC providers, but don't currently have other alternatives.

Regards,

Josh

[Discuss]

Hi Josh, 

thanks for the info. 
What is the reasoning (from a security standpoint) of validating the OIDC Identity Provider/Server ? Most sites will have a  regular Azure tenant and not a B2C tenant.
We do have a B2C tenant but we are currently not using it and we also don't have our users synched there and we want to avoid doing this. Are there any plans to support regular Cloud OIDC endpoints without a custom domain in the near future ? 

Best

Ümit

[Josh Bryan]

Umit,

Globus namespaces its usernames by the domain portion of username and trusts a single identity provider to authenticate those identities.  E.g. we trust the University of Chicago to assert jbr...@uchicago.edu as a username in our ecosystem.  Many of these domain mappings are managed by the InCommon federation and we sync our mappings with that list.  In order to prevent situations where someone registers an OIDC server that may present globus with identities from NotYetAnInCommonMember.edu even though that org may eventually be an InCommon member, we need to verify that whoever is setting up that OIDC server has a reasonable ability to claim to represent NotYetAnInCommonMember.edu.  If we didn't, someone could claim that domain before the real organization does, or worse, they could use that ability in social engineering attacks and appear as though you are sharing data with someone trusted.  

One easy way to do that validation is to show proof of ownership of the domain at which the OIDC server is running.  This works well for most use cases, but there are some edge cases like yours.  We have had some conversations about providing other mechanisms for validation or supporting different ways of namespacing identities, but we do not have any near term plans or timelines for those features.

Regards,

Josh

[Ümit Seren]

Hi Josh, 

thanks for the explanation. 

I have an unrelated questions: Are the metadata for the federated IDPs updated regularily or manually? 
We recently updated our IDP (Shibboleth) and added an additional domain (services.vbc.ac.at) that should be authorized.
Now we tried to update our storage gateway and add the specific domain, however we receive following error message:

An API Error Occurred
HTTP status: 422
code:        unprocessable_entity
message:     Globus Auth does not have an identity provider registration for the following domains, so they can not be used with Globus Connect Server: services.vbc.ac.at

Also we noticed that the description of our IDP in the federated list is still the old outdated description. 

Thanks in advance

Best

Ümit

[Josh Bryan]

Umit,

There is an automated process that will sync once a day, however changes to domain names may not always get reflected in globus for a variety of reasons.  I've checked the InCommon metadata and do see the added domain, so I've gone ahead and updated it in our system.  However, we use OranizationDisplayName in our drop down and don't see any changes to that so I have left it as is.  In the future, I'd suggest raising issues with updates to federated IdPs by opening a ticket with sup...@globus.org as it can get routed to the right teams more quickly.

Regards,

Josh

[Ümit Seren]

Josh, 

thanks for the fix.
We successfully updated the gateway and added the additional domain. In future we will raise a ticket for IdP related issues. 

Best

Ümit