Azure AD without ADFS

[Admin IFMSA-Sweden]

Can I ask another question?

Microsoft ACS supports multiple ADFS (WS compatible STS) but not SAML2 and has ”Home Realm Discovery”.

Azure AD supports ADFS and SAML2 - is there any option where Shibboleth IdPs can be federated with Azure AD (without our own ADFS), and eventually add Shibboleth federation metadata to Azure AD? As mentioned, we don’t have our own ADFS.

What do you think about interoperability between Azure AD and Shibboleth?

Am I asking a wrong question? Should I think this another way?


Thanks

Mats

> 2 maj 2017 kl. 18:12 skrev Peter Schober <peter.schober at univie.ac.at>:
> 
> * Admin IFMSA-Sweden <admin at ifmsa.se> [2017-05-02 17:58]:
>> Our old portal uses a linux Shibboleth SP and SWAMID federation (in
>> Sweden) which requires signing of their certificate. We are moving
>> to Dynamics 365 and our old SP will be terminated.
> 
> I very much doubt that you had to sign SWAMID's certificate, that's
> not how federation works. (The federation provides you with signed
> metadata, and you may decide to trust that signature.)
> In the most simple/common deployment an SP doesn't sign /anything/.
> 
>> Our new portal is a Microsoft "cloud-component” which we have not
>> control over. We can login via Shibboleth IdPs and ADFS, however,
>> according to a consultant (at Kentor in Sweden) that our new
>> Dynamics portal seems not have ability to use federation metadata
>> with multiple IdPs, and does not provide own key or can sign a
>> certificate (there is a metadata in our Azure AD). Moreover, the
>> requirement of generation of persistent name ID points us towards
>> use of federation metadata rather than asking each IdP (I guess this
>> could be needed for Office 365).
> 
> OK, I see that this product allows to use SAML IDPs to log in:
> https://www.microsoft.com/en-us/dynamics/crm-setup-and-administration/saml-2-0-provider-settings-for-portals.aspx
> That page does not seem to cover how to add that IDP as trustworthy
> source of identities/attributes to the product itself (which is the
> part that SAML 2.0 "federation" metadata would solve), but the
> reverse: How to add this SP to IDPs to be used for externalized
> access.
> 
> AFAICT the question of "federation" metadata, i.e., SAML 2.0 metadata
> with lots of entitis (here: IDPs) it it, does not come up here at
> all. Only if maybe you're thinking that Microsoft (as the provider of
> that SaaS offering) should now become a member of SWAMID, so that all
> SWAMID IDPs can continue to leverage the benefits of federation as
> they were able to, when you still ran your own SAML SP.
> Again, that's not something the Shibboleth software community can
> comment on, that would be for Microsoft and SWAMID to say.
> 
> 
>> Yes. I am also lost. Actually, we would like to try to avoid hosting
>> our own IdP/SP/proxy and use as much of resources that is currently
>> available to us.
> 
> Either the SaaS offering you're interested in does what you want, or
> it doesn't. (This is the wrong community to ask about it, of course.)
> If it doesn't you can stand up your own infrastructure to work around
> the service's/product's deficiencies, or you may decide to look
> elsewhere. Those usually are the two options when buying services from
> global giants. (The third option of thowing money at the vendor to
> implement the missing pieces is likely out of reach here.)
> 
>> Sorry for all the confusions. I am really lost here. Just trying to
>> understand which direction we should take, and how to think. I have
>> only experience with SP, and not much with IdP in Shibboleth.
> 
> All your questions here are about use of non-Shibboleth software.
> So this community is not best positioned (or staffed, or motivated, to
> be honest) to advise on that.
> -peter.
> -- 
> To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net