Main Nav

Hello IdM Community,

We are facing a couple of challenges here at the University of Colorado Denver | Anschutz Medical Campus that I anticipate some of you have worked to conclusion, and therefore would like to ask for your insights. 

 

A bit of our environmental background is that we are an Oracle Identity Management (OIM) shop, focusing our energies on making that suite (OIM, OVD, OID, OIF, OAM) of products as productive as possible for us.  We also rely heavily on Microsoft for messaging services, having a large majority of our constituency supported by Live@edu, and moving in the near future to Office 365, while also maintaining on premises exchange services for some portions of our constituency.

 

Now for the questions:

1)      Given our environment, we believe that the simplest and most effective provisioning approach would be to use OIM to provision to O365 directly through either power shell or web-service calls.  Have any of you accomplished this type of integration from OIM or another non Microsoft IAM product or system?  If so, can you share some of your insights to getting that done in a way that is Microsoft supported?  Theoretically this all sounds doable, but I am interested in the technical minutia of how to really make it work.  (for the record, we are currently funneling this through AD and FIM)

2)      Again, given our focus, we would prefer to implement federated authentication to O365, while not instantiating a huge Microsoft stack on our side.  Have any of you done this using Shib or OIF to present a user directly to O365?  What about proxying that connection through a local ADFS?  Again, I think that these are theoretically possible, but am interested in hearing the challenges faced in getting this done.

My apologies if these topics have been covered (couldn’t find archival info, but could be the search strings used). 

 

Thanks in advance for your assistance and insights.

 

Miah

 

Jeremiah Adams |Identity Management Architect

Ph: 303-315-2804 | miah.adams@ucdenver.edu | ucdenver.edu/its

 

 

AttachmentSize
image001.jpg4.55 KB

Comments

We're still in the planning stages of our implementation, but I've discussed both of these issues at length with Microsoft.

1) Mirroring AD accounts using FIM is the only Microsoft-supported way to create accounts in O365.  According to the people I've talked to, there are no plans to open the web service interface used by FIM to 3rd party apps.  As you said, it should be possible, but until MS opens the API and supports it's use, it isn't going to happen.

2) Using Shibboleth for web-based authN to O365 isn't technically supported, but it does work and I was told that there are several schools already using in production.  The engineer we are working with said that he expected that use of Shibboleth will be supported "eventually", but there is the *huge* caveat that fat clients (Outlook, etc) will not work.  Even with official MS support, losing the ability to use Outlook is a deal-breaker for us, so we're going with ADFS as the IdP.

-Eric 

ADFS can, in turn, use Shibboleth as the ultimate IdP, which, I believe, will enable the fat clients to then work.

 

 

 

From: Identity Management Constituent Group Discussion list [mailto:IDM@LISTSERV.EDUCAUSE.EDU] On Behalf Of Eric Pierce
Sent: Wednesday, July 25, 2012 3:03 PM
To: IDM@LISTSERV.EDUCAUSE.EDU
Subject: Re: [IDM] Office 365 Provisioning and Federation Options

 

We're still in the planning stages of our implementation, but I've discussed both of these issues at length with Microsoft.

 

1) Mirroring AD accounts using FIM is the only Microsoft-supported way to create accounts in O365.  According to the people I've talked to, there are no plans to open the web service interface used by FIM to 3rd party apps.  As you said, it should be possible, but until MS opens the API and supports it's use, it isn't going to happen.

 

2) Using Shibboleth for web-based authN to O365 isn't technically supported, but it does work and I was told that there are several schools already using in production.  The engineer we are working with said that he expected that use of Shibboleth will be supported "eventually", but there is the *huge* caveat that fat clients (Outlook, etc) will not work.  Even with official MS support, losing the ability to use Outlook is a deal-breaker for us, so we're going with ADFS as the IdP.

 

-Eric 

We did no-prompt authN from Outlook to O365 via ADFS during our pilot test, but have not gone prod yet due to contractual issues. But, it does work (sorry, no URL to give you). > -----Original Message----- > From: Identity Management Constituent Group Discussion list > [mailto:IDM@LISTSERV.EDUCAUSE.EDU] On Behalf Of Cantor, Scott > Sent: Wednesday, July 25, 2012 4:25 PM > To: IDM@LISTSERV.EDUCAUSE.EDU > Subject: Re: [IDM] Office 365 Provisioning and Federation Options > >

The Microsoft Online SignOn Assistant (http://community.office365.com/en-us/wikis/office/534.aspx) authenticates with ADFS and requests a WS-fed token that is passed by Outlook to O365.  The other option is that Outlook sends the username/password as normal to the O365 servers, which then proxies the authentication request back to the on-premises ADFS servers before allowing access.

-Eric 


Folks interested in this topic may want to join the Office 365 for Education mailing list, office365@ucdavis.edu. Directions to join list:

 

-Send a message to sympa@ucdavis.edu from the address you want to subscribe to the list.

-In the subject line of your message, type in: subscribe office365 FirstName LastName. Leave the message body blank.

 

There's an active number of HiEd folks looking at O365 there plus quite a few Microsoft Education employees.

 

I'd counter both #1 & #2 below.

 

#1: There are actually quite a few ways to create O365 accounts. *At this time*, there is only one publicly supported way to create O365 accounts and leverage federated authentication against those accounts, and that is via the DirSync "appliance" which is just a specialized installation of ILM/FIM which must take its source of accounts from Active Directory. Microsoft has heard pretty clearly that this isn't an acceptable situation long term, so you shouldn't expect it to continue indefinitely. You can actually create O365 accounts many other ways, but the DirSync method is currently the only publicly supported way which allows you to set the "immutable identifier" that Microsoft requires to lash up federated authentication to those accounts. Microsoft (via a couple key blog posts over the past couple months) has publicly revealed an intention to provide a web service API to interact with Windows Azure Active Directory, which is what is behind Office 365 accounts. So at some point, Microsof has publicly noted there will be other provisioning methods, but no details have yet publicly surfaced. (if folks want the URLs of the blog posts I can provide those)

 

#2: To my knowledge, Microsoft hasn't announced SAML support for Office 365, but has been saying it would add that support "soon" since at least April 2011. However, based on this public documentation http://technet.microsoft.com/en-us/library/jj205456, which appeared at about the same time as the launch of the Office 365 for Education offering, it appears that they do now support Shibboleth federation. I haven't yet heard any Microsoft employee make a statement about this.

 

I can also report that we plan to test (real soon now) a configuration with Shibboleth chained in front of ADFS in front of O365 (i.e. in ADFS: Shibboleth is a claims provider & O365 is a relying party). We know this kind of chained federation configuration works for other "ADFS centric" Microsoft applications, but haven't yet tried it with an active client (vs. a passive/browser client) like Outlook. We'll also look at some more complex configurations like trying to redirect all passive Office 365 clients to Shib, but keeping all active Office 365 clients with ADFS (to preserve the "single sign-on" for those that can do it, but allow the familiar Shibboleth logon experience for everyone else). I've mentioned this plan on both the office365@ucdavis.edu mailing list, as well as the windows-hied@lists.stanford.edu mailing list, as well as other things we are trying with ADFS and Shibboleth together. We don't see any way to avoid deploying ADFS, so are seeking some sane way for them to co-exist, leverage the strengths each has, and try to avoid building too much duplicate support infrastructure.

 

Brian Arkills

 

From: Identity Management Constituent Group Discussion list [mailto:IDM@LISTSERV.EDUCAUSE.EDU] On Behalf Of Eric Pierce
Sent: Wednesday, July 25, 2012 1:03 PM
To: IDM@LISTSERV.EDUCAUSE.EDU
Subject: Re: [IDM] Office 365 Provisioning and Federation Options

 

We're still in the planning stages of our implementation, but I've discussed both of these issues at length with Microsoft.

 

1) Mirroring AD accounts using FIM is the only Microsoft-supported way to create accounts in O365.  According to the people I've talked to, there are no plans to open the web service interface used by FIM to 3rd party apps.  As you said, it should be possible, but until MS opens the API and supports it's use, it isn't going to happen.

 

2) Using Shibboleth for web-based authN to O365 isn't technically supported, but it does work and I was told that there are several schools already using in production.  The engineer we are working with said that he expected that use of Shibboleth will be supported "eventually", but there is the *huge* caveat that fat clients (Outlook, etc) will not work.  Even with official MS support, losing the ability to use Outlook is a deal-breaker for us, so we're going with ADFS as the IdP.

 

-Eric 

Microsoft (via a couple key blog posts over the past couple months) has publicly revealed an intention to provide a web service API to interact with Windows Azure Active Directory, which is what is behind Office 365 accounts. So at some point, Microsof has publicly noted there will be other provisioning methods, but no details have yet publicly surfaced. (if folks want the URLs of the blog posts I can provide those)

 

[BA] Looks like I was out of date, so I'm correcting myself before someone else does. :)

 

On July 12, Microsoft did release some details, when it made available the developer preview bits for WAAD. In specific, that developer preview has REST APIs that give read access to WAAD, and the announcement promises to later provide write operations. It also says "over the coming months we will release updates which broaden our protocol coverage to support authentication protocols commonly used on the internet including SAML 2.0." See http://blogs.msdn.com/b/windowsazure/archive/2012/07/12/announcing-the-d... for all the gory details announced--and that URL has links to most of the URLs I alluded to above.

 

Also, I've now found an announcement of Office 365 support for Shibboleth: http://blogs.technet.com/b/educloud/archive/2012/07/05/using-shibboleth-.... It notes "rich client support including IMAP, POP, EAS, MAP, Outlook 2007". I'm betting MAP is a typo, and should be MAPI. :)

 

-B

Message from wgthom@gmail.com

Unicon prototyped a simliar solution for Julliard earlier in the year.

O365 -> ADFS -> Shib -> CAS -> AD

I believe the DS at ADFS could have been by-passed with a little more monkey grease.

In any case sounds like we can remove ADFS now. :)

Bill



Close
Close


Annual Conference
September 29–October 2
Register Now!

Events for all Levels and Interests

Whether you're looking for a conference to attend face-to-face to connect with peers, or for an online event for team professional development, see what's upcoming.

Close

Digital Badges
Member recognition effort
Earn yours >

Career Center


Leadership and Management Programs

EDUCAUSE Institute
Project Management

 

 

Jump Start Your Career Growth

Explore EDUCAUSE professional development opportunities that match your career aspirations and desired level of time investment through our interactive online guide.

 

Close
EDUCAUSE organizes its efforts around three IT Focus Areas

 

 

Join These Programs If Your Focus Is

Close

Get on the Higher Ed IT Map

Employees of EDUCAUSE member institutions and organizations are invited to create individual profiles.
 

 

Close

2014 Strategic Priorities

  • Building the Profession
  • IT as a Game Changer
  • Foundations


Learn More >

Uncommon Thinking for the Common Good™

EDUCAUSE is the foremost community of higher education IT leaders and professionals.