Azure AD without ADFS

Admin IFMSA-Sweden admin at
Tue May 2 12:07:08 EDT 2017

> 2 maj 2017 kl. 17:57 skrev Peter Schober <peter.schober at>:
> * Admin IFMSA-Sweden <admin at> [2017-05-02 17:29]:
>> We have a portal for Dynamics 365 using multiple external identities
>> for sign-in, e.g. Shibboleth IdP and ADFS. More info regarding the
>> SP can be found here:
>> <http
> OK, so that's an application hosted (SaaS) by Microsoft "unifying the
> capabilities of CRM business software and ERP systems".
> And you're trying to connect SAML IDPs to that, presumably those of
> academic institutions? Then the protected resource would have to be
> able to act as a SAML 2.0 Service Provider. The page doesn't say
> anything about SAML, and the screenshot in section "Manage external
> accounts" only lists:
> Facebook, Google, Windows Live™ ID, WS-Federation, Yahoo!
> One or two tings here are protocols, the rest IDPs. None are about SAML? <>

Yes, we do have several working external logins already, both Shibboleth and ADFS.

>> We have not found this portal to be capable to consume Shibboleth
>> IdP Federation with IdP Discovery Service which requires signing of
>> keys and certificates. Even though we are still trying to find ways
>> to connect through Shibboleth IdP Discovery Service (i.e. Proxy
>> IdP), we look at same time other ways to achieve almost the same
>> result
> Are you saying you're able to hook up individual SAML 2.0 IDPs
> (possibly of the Shibboleth implementation, but that's really
> irrelevant here) to that resource and use them for externalized
> authentication and authorization?  And that the product does not allow
> consuming definitions of SAML 2.0 IDPs in machine-readable format
> (i.e., via SAML 2.0 Metadata)?  Or that you can define many SAML IDPs
> in the product but that you have no way to select a specific IDP?

We can add one IdP at a time. However we might end up with adding so many IdPs that we don’t have resources to handle individually. I think the problem arises with generation of persistent name ID which is not yet default for many IdPs, we could add IdPs individually and ask for persistent id, however, it would be nice to get it from federated metadata, that is to save time for us all. Anyways, the portal doesn’t have it’s own metadata with keys and we can’t sign federation metadata anywhere.

Proxy IdP is really not an ideal solution or situation we as a small organization with limited resources want to be in. Since Azure AD has a couple of options, I am trying to find ways to use it, or we have to have our own Proxy IdP, else we will add individual IdPs one by one (which I guess will require more maintenance).



> Totally guessing based solely on some of the words you used.
> -peter
> -- 
> To unsubscribe from this list send an email to users-unsubscribe at

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the users mailing list