Azure AD without ADFS

[Admin IFMSA-Sweden]

> 2 maj 2017 kl. 18:30 skrev Peter Schober <peter.schober at univie.ac.at>:
> 
> * Admin IFMSA-Sweden <admin at ifmsa.se> [2017-05-02 18:07]:
>> 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.
> 
> ACK. So if the SP implementation (the MS product here) does't offer
> more scalable methods you can either look elsewhere or own the
> problem of adding infrastructure to make this process scale.
> 
> (And yes, the latter would probably look like you standing up a SAML
> IDP, hooking that up to the product as the only SAML IDP, and
> protecting that SAML IDP with another SAML SP of your own, and *only*
> exposing that latter SP to the IDPS in SWAMID and beyond.)
> 
>> 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.
> 
> Like I tried to explain, SAML 2.0 Metadata is merely a collection of
> technical data describing SAML entitis. While SAML Metadata may
> include a *declaration* that a given SAML IDP supports persistent
> NameIDs it's not the SAML Metadata that makes the IDP support that.
> Metadata is purely descriptive here.
> 
> You're probably right in that many IDPs will not support persistent
> NameIDs (since doing that properly comes with non-trivial costs and/or
> identity management requirements). But then those IDPs to not support
> persistent NameIDs and nothing you (or SWAMID) put(s) into "federation
> metadata" can change that.
> 
> In short: The requirement of the SP (the MS product here) that all
> SAML IDPs need to supply persistent NameIDs is the problem here (and a
> bit silly, too). Whether you talk to (or configure) those IDPs
> individually or via "federation" does not change anthing here:
> Either an IDP (e.g. an academic institution) supports persistent
> NameIDs, or it doesn't.
> 
>> Anyways, the portal doesn’t have it’s own metadata with keys and we
>> can’t sign federation metadata anywhere.
> 
> The instructions ("Shibboleth Identity Provider 3")
> https://www.microsoft.com/en-us/dynamics/crm-setup-and-administration/saml-2-0-provider-settings-for-portals.aspx
> describe how to hand-create SAML 2.0 metadata for the SAML SP specific
> for your "portal". That's the "portal's own metadata".
> And yes, it does not seem to publish a cryptographic key (at least
> those "instructions" don't mention one), but that only means that a
> SAML IDP cannot encrypt the SAML response (or assertion) to the
> SP. That's sad (as it means data sent from the IDP may be exposed in
> certain certainstances; also it means many of the IDPs may have to
> perform manual steps to make their IDP work with such an SP), but this
> has nothing to do with hooking up IDPs to that SP.
> 
> And it's not you signing "federation metadata" unless you're trying to
> etablish a new federation.
> 
>> 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).
> 
> Those are still several concerns and topics all mashed together.
> 
> If (what I assume is a given) the SAML IDPs you want to hook up to
> your "portal" do not all support persisten NameIDs (as required by the
> MS product) then either they can't participate (hurting your business)
> or *you* would have to stand up and run the needed infrastructure and
> create and manage persistent NameIDs on behalf of all subjects from
> all those IDPs (which is possible, but possibly messy, and either way
> not something you do on the side, once.)
> As explained, that would be running a SAML SP, plus a SAML IDP, plus a
> data store with mappings from external identies to locally generated
> persistent NameIDs). You might find that SimpleSAMLphp is easier to
> set up for that particular use-case than using Shibboleth software,
> but it's certainly possible with both (or yet others).
> 
> "Trying to find ways to use Azure AD" is fully off-topic here.
> 
> And how you add those IDPs is yet another difference topic, but I
> think we've covered that between the last few emails?
> 
> -peter

Thanks Peter for your explanations !

Regards

Mats


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