Azure AD without ADFS

[Peter Schober]

* 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