Azure AD without ADFS

Peter Schober peter.schober at
Tue May 2 12:57:28 EDT 2017

* Peter Schober <peter.schober at> [2017-05-02 18:41]:
> But nothing here changes anything wrt the specific points surfaces
> during this discussion:
> * If the SP (MS here) requires you to hook up IDPs individually and
>   manually, you'll suffer. (Either by doing just that, or by investing
>   into standing up alternatives that scale.)

Of course we could dissect all of this even further. E.g. first get
all the IDPs into the MS product, using whatever tools or APIs or even
scripting they offer. People have been doing that to integrate MS-ADFS
as SAML 2.0 IDP/SP with "federations" (i.e., lots of SAML2 entities)
without manually clicking thouh GUIs for trust establishment,
cf. pysfemma (the port of the abandoned pyFemma tool to Roland's
pysaml2, spitting out PowerShell code, or whatever).
I would like to think something like that should be possible with an
SaaS offering from the same vendor, too. I may be wrong, of course.
(E.g. may be another good basis to ingest metadata
provided by SWAMID and spitting out whatever you need to automatically
provision IDPs into the MS product at hand here..)

Then tackle the reverse side of the problem: Getting SAML 2.0 Metadata
about the SP (your "portal" hosted by MS here) into SWAMID. Best talk
to SWAMID about that, as that may depend on too many specifics not
suitable for this list. SWAMID also knows a thing or two about MS, so
chances are they in a good position to help you.

> * If the SP (MS here) requires all IDPs to support persistent NameIDs,
>   you'll suffer. (Either by spending your days nagging universities
>   and research institutions and whatnot to implement persistent
>   NameIDs so their students can access your service. Or by investing
>   into standing up alternatives that scale, at possibly significant
>   ongoing cost.)

I don't really see a way around that, though. Either the product can
be configured to lessen that restriction (making it configurable,
ideally) or you'll have to stand up a proxy to make up for the lack of
persistent NameIDs at many institutions throughout the world (or
Sweden). To some degree that moves the issues (and cost) related to
supporting persistent NameIDs from the instiutions to your proxy
(thanks to MS's insistence on those), but I've seen vastly varying
approaches to supporting persistent NameIDs, and you might get a way
with something "cheap and dirty", esp if you're prepared to deal with
the occasional fallout (e.g. handling issues when someone lost access).


More information about the users mailing list