Shibboleth for Office 365 (Authentication decision)

[solution79]

Hello Nate,

 

First of thanks for responding.

Sorry but going through the Microsoft article, I have few basic & probably
stupid questions. But request the user community including Nate to respond
as it will help to get the concept clear.

 

b)      b) If yes, then the attribute for authentication can be the user
login id rather email address, as we are using it currently.

 

Office365 wants an "ImmutableID" for your users.  You will need to decide
what identifier is most immutable, unreassigned, persistent, etc. and send
it.  It needs to, again, match the back-channel provisioning.

 

May I understand that every id placed in the LDAP - SUN Enterprise need to
have an Immutable ID field as well.

I guess, still not clear on this.

Will the UPN act as an immutable id? - I felt for a moment.

But as the Microsoft -
http://technet.microsoft.com/en-us/library/jj205463.aspx#BKMK_1 

 

Windows Azure AD ImmutableID

Windows Azure AD requires you select a unique identifier for each user in
your user directory. You must also configure Shibboleth to send this
attribute on each federated login to Windows Azure AD in the SAML 2.0 NameID
assertion. This identifier must not change for this user over the lifetime
of the user being in your system. The Windows Azure AD Service calls this
attribute the "ImmutableID". The value for the unique identifier must not
contain domain information and is case-sensitive.

For example, do not use user at contoso.com. In the recommended code below, the
value used will be the Active Directory objectGUID property that is
base64-encoded. When creating accounts, you must ensure the ImmutableID is
processed the same way or the user will not be able to sign in to the
Microsoft cloud service. The Windows Azure Active Directory Sync tool
automatically uses the Active Directory objectGUID for the ImmutableID value
and processes the ImmutableID the same way as in the following recommended
example:

 

Which make me understand that I need the AD object GUID, but how can I
derived that as I am using LDAP - SUN Enterprise?

 

c) c)       Once replaced with Shibboleth for Email access. Now user logs to
Student portal using their Student Login id, post authentication while
clicking on "My Email" will Shibboleth pick the email address from the
cookie session and provide the same to Office 365 thus allowing user a SSO
experience to access emails?

 

"My Email" probably leverages a field in your back-channel
provisioning(likely mail), but it could try to build an email address for
the user using ImmutableID.  This is a question to ask to Microsoft and
another potential area of improvement.

 

In my case:

1)      clicking "My Email" will route the request to Office365.

2)      which in turn will route the request back to Shibboleth IDP and here
the browser will provide the session cookie that would authenticate to
Shibboleth. 

3)      Post authentication, Shibboleth should provide the immutable id
details to ADFS and thus allowing the user to log to Office 365 with SSO
experience.

Is the process flow correct?

 

 

New Question:

Microsoft Article suggest - Install Windows PowerShell for single sign-on
with Shibboleth

Ref:  <http://technet.microsoft.com/en-us/library/jj205464.aspx>
http://technet.microsoft.com/en-us/library/jj205464.aspx

 

Do we need to install the Windows Azure Active Directory Module on the
Shibboleth server or it be any Windows Based server?

 

Regards,

 

Dematri

From: users-bounces at shibboleth.net [mailto:users-bounces at shibboleth.net] On
Behalf Of Nate Klingenstein
Sent: Thursday, June 6, 2013 2:00 AM
To: Shib Users
Subject: Re: Shibboleth for Office 365 (Authentication decision)

 

Dematri, 

 

Looking for valuable advice for the below scenario in order to implement
Shibboleth for Office 365.

 

The best advice I can offer is to please encourage Microsoft to work on
their implementation/documentation so we don't have to field so many Office
365 questions.

 

a)      Our Shibboleth is getting authenticated by LDAP - SUN Enterprise
Directory 5.2. Therefore from Shibboleth Federation with Office 365
perspective, can it use the same LDAP to authenticate users rather than AD?

 

The account information coming from Shibboleth will need to match the
account information provisioned to Microsoft(for now, with a strange little
tool called DirSync).  If your data in both matches, then you can use the
same LDAP.





b)      If yes, then the attribute for authentication can be the user login
id rather email address, as we are using it currently.

 

Office365 wants an "ImmutableID" for your users.  You will need to decide
what identifier is most immutable, unreassigned, persistent, etc. and send
it.  It needs to, again, match the back-channel provisioning.





However I understand for SSO to Office 365 you need to provide email
address. Is it possible to have the email address in the background provided
by Shibboleth to Office 365?

 

It's not clear to me that they're asking for email address in addition.  But
that's going by their documentation, so I could very well be wrong.

 

http://technet.microsoft.com/en-us/library/jj205463.aspx

 

c)       Once replaced with Shibboleth for Email access. Now user logs to
Student portal using their Student Login id, post authentication while
clicking on "My Email" will Shibboleth pick the email address from the
cookie session and provide the same to Office 365 thus allowing user a SSO
experience to access emails?

 

"My Email" probably leverages a field in your back-channel
provisioning(likely mail), but it could try to build an email address for
the user using ImmutableID.  This is a question to ask to Microsoft and
another potential area of improvement.

 

Thanks,

Nate.

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://shibboleth.net/pipermail/users/attachments/20130606/0f63922d/attachment-0001.html