Azure AD without ADFS

[Admin IFMSA-Sweden]

> 2 maj 2017 kl. 17:44 skrev Peter Schober <peter.schober at univie.ac.at>:
> 
> * Admin IFMSA-Sweden <admin at ifmsa.se> [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. [...]
>> 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.
> 
> It's not evident to me what what part of the Shibboleth project or
> software you're looking to find support for.
> 
> There's no such thing as "Shibboleth IdP Federation". There are
> Shibboleth implementations of standard protocols (OASIS SAML 2.0 here,
> most likely) available as Free/Libre/Open Source software.  Also
> there's SAML 2.0 Metadata, which you can use to build "federations",
> but which really just are text (well, XML) files that contain SAML
> entities (a single one, or thousands).
> With SAML Metadata being just text files of course you'd be
> well-advised to only ever consume those over the Internet when its
> signed with a trustworthy key, but neither Shibboleth not the SAML
> specification mandate this.  (Also IDP Discovery Services have nothing
> to do with "signing of keys and certificates".)
> 
> So you've already lost me here.

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.

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

>> 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 (can this be done
>> with Azure AD). (For ADFS IdPs this can theoretically be achieved
>> with Microsoft ACS/AccessControlService for WS-compatible STSs,
>> however, ACS is to be replaced with Azure AD, I assume).
> 
> Sorry, I don't speak enough MS to understand any of that.
> But a SAML IDP Discovery Service is not at all the same thing as
> Proxy.

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.

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.

Thanks

Mats


> Maybe others will know what it is you're after.
> -peter
> -- 
> To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net