Azure AD without ADFS

[Admin IFMSA-Sweden]

> 2 maj 2017 kl. 18:57 skrev Peter Schober <peter.schober at univie.ac.at>:
> 
> * Peter Schober <peter.schober at univie.ac.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. http://pyff.io 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).
> 
> -peter

Thanks a lot for your advice :)

I’ll need to read your answers and think for a while before I ask anything more.  

We are also waiting for support answer from Microsoft, there is a template for each product and hopefully we will get an answer from the right team/s soon.

Regards

Mats

> -- 
> To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net