-----Original Message-----

From: Discussion list for Shibboleth developments [mailto:[log in to unmask]] On Behalf Of Alistair Young



>I’m curious whether Azure AD itself is a ‘better’ IdP than the actual ‘Shibboleth’ IdP registered as a tenant app



[Andy Swiffin>]

It depends on the definition of better.  Certainly as far as we can see it's nowhere near as capable ...  at the moment.   Whether they can be influenced to add what we need remains to be seen



>and therefore able to make use of SSO,

[Andy Swiffin>]



Ahh there you have it.   We authenticate Office365 through Azure (direct, no adfs or any of that jazz).   We also authenticate our Servicedesk there and get SSO with that.  Our new finance/HR/Student records system also authenticates there, with SSO too.   We could move Blackboard there,  and Box.   When windows 10 desktop comes here, that will authenticate to Azure.  Hence SSO between all the above, isn't that "better"?    If we can do this, then authenticating external Service Providers should be possible.   Of course the lack of mechanism for automatically processing external metadata would currently be an issue, some things may be possible with powershell.  When you have a proper look at the resources that are actually being accessed from our site there are in reality not that many.   However who knows what Microsoft can be persuaded to add with a chance of a good slice of this pie?



>I would think the standard IdP as tenant app would give more flexibility in how attributes are munged to other attributes,

>as opposed to storing supplier specific attributes in Azure AD.



[Andy Swiffin>]



That's one possibility and authenticate that against the LDAP from AAD Domain services.  But then you'd lose SSO with all of the above.   It is definitely something we're considering to put the IdP in the cloud and at least take away that reliance on on-premise components.   We have sight of one document which talks about making schema extension available in Azure AD, it's at an early stage, but moving in the right direction.



>Something that comes up is the pricing for syncing local AD data with Azure. The more you sync the more it costs.

>In that context would it make sense to sync the basics and let the IdP take care of how suppliers see those attributes?

>Or is it more attractive to absorb any extra cost in order to have a single solution to federated access?



[Andy Swiffin>]



I'm not really sure what you mean here,  if you've got office 365, you've got Azure, there is no cost in syncing extra attributes, or for that matter extra users.   I have a suspicion that to do all we want you would need AAD Premium licencing, in our case we already have that and the cost has been well justified in the support savings over password management calls alone.  It certainly has opened doors for us.



As it stands, I don't believe we could rip out Shibboleth, today, and rely on Azure AD as our IdP.  But, the tests we've done so far reveal it's far more capable than we had first thought it would be.   AND we're already paying for/have/need Azure AD, we have no choice, and so we're asking ourselves why do things twice when we can have someone else do all this for us?.    If Azure AD SAML can be made more flexible then I don't see why ultimately it can't fulfil this role.  And, from all I see, I think there may be the will within Microsoft to listen to the requirements.



These days we have too many demands on too few staff and too few resources to do some of the things we did in olden days, I think it's time to think again around this whole area.



My tuppence.

Andy





The University of Dundee is a registered Scottish Charity, No: SC015096