Azure AD without ADFS

[Peter Schober]

* 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.