[Shib-Users] Protecting Sharepoint with Shibboleth SP

[Eitan Eibschutz]

Hi,

 

Did anyone try to protect Sharepoint 2007 with Shibboleth SP? Is this possible?

 

Thanks,

 

Eitan

 

[Caskey, Paul]

You have to switch Sharepoint to forms-based authentication.  Then, you need a Sharepoint MembershipProvider that integrates with Shibb (write it or buy it).  However, using this method disables all of the webDAV functionality, like being able to save MS-Office files directly into Sharepoint.

 

I know of "Shibb'd Sharepoint" being done both with a product from CA and a product from 9StarResearch.

 

We are using the latter product for our federated Sharepoint installation.

 

There was a group that met a few times to discuss issues around federated Sharepoint, but the group is not currently meeting.  The archives, along with other perhaps useful information, is located here: https://spaces.internet2.edu/display/InCCollaborate/InC-SharePoint

 

 

---

From: Eitan Eibschutz [mailto:Eitan.E...@hyro.com]
Sent: Tuesday, February 03, 2009 10:44 PM
To: shibbole...@internet2.edu
Subject: [Shib-Users] Protecting Sharepoint with Shibboleth SP

[Peter Williams]

http://blog.pingidentity.com/blog/default/2007/09/25/New-PingFederate-Sharepoint-Integration

 

blog does not indicate the same restrictions as the Shib derivatives; but has license fees.

[Chad La Joie]

Whether their marketing blurb indicates it or not, those problems are
going to be there. The issue isn't anything to do with Sharepoint
itself as much as it is that DAV clients don't support SAML.

--
SWITCH
Serving Swiss Universities
--------------------------
Chad La Joie, Software Engineer, Net Services
Werdstrasse 2, P.O. Box, 8021 Zürich, Switzerland
phone +41 44 268 15 75, fax +41 44 268 15 68
chad....@switch.ch, http://www.switch.ch

[Peter Williams]

Sure, but id still expect Microsoft-enhanced DAV to work as normal - as opposed to being disabled. IF one has an local account on the webdav server, webdav clients can still use the same mechanism they to today to access office file repositories. IN a federated directory environment (in a federated university MAN, like London), the very same two sites that are federating at the SAML level can be similarly federating at the activeDirectory level, so kerberos makes federated-named between the 2 ldap naming contexts (and their domain controllers).

[Bucci, Debbie (NIH/CIT) [E]]

CA – one here …essentially the same solution … Forms based auth - believe we got pass the webDAV issue by using ldap as membership provider for people picker functionality – but had to fall back to SharePoint provisioned groups.

 

From: Caskey, Paul [mailto:pca...@utsystem.edu]

Sent: Wednesday, February 04, 2009 12:50 AM
To: 'shibbole...@internet2.edu'

[Bucci, Debbie (NIH/CIT) [E]]

Let me clear - this is not a CA solution - not promoting the use of any product. Any flavor Webauth -forms based.

---

From: Bucci, Debbie (NIH/CIT) [E]
To: 'shibbole...@internet2.edu'
Sent: Wed Feb 04 06:08:45 2009
Subject: RE: Protecting Sharepoint with Shibboleth SP

[Caskey, Paul]

Hi Debbie-

 

Thanks for that.  I would be curious to hear how you got around the webDAV issues with LDAP.  From my understanding, it is the office tools (MS-Word, etc) that open the files that do not understand SAML (or LDAP, for that matter).

 

---

From: Bucci, Debbie (NIH/CIT) [E] [mailto:bu...@exchange.nih.gov]
Sent: Wednesday, February 04, 2009 5:09 AM

To: 'shibbole...@internet2.edu'
Subject: [Shib-Users] RE: Protecting Sharepoint with Shibboleth SP

[Peter Williams]

For many, many years, Microsoft (web) server applications have created security contexts based on the presentation of NT tokens (which you can think of conceptually as SAML assertions tied to the Network Operating System). If the client has a token in a domain that uses one ldap namespace for authentication, active directory nodes can use Kerberos to translate the token from that directory into the token normally authenticated by another directory instance – the one bound to the server domain. Thus, by leveraging inter-forest trust (between namespaces), one can present a suitable inter-domain token to the reference monitor of the server host/cluster.

 

This is not advanced academic stuff!

[Moni Patil]

 

We are protecting Sharepoint 2007 with Shibboleth SP.

 

The implementation is pretty simple. You need to write your own Membership Provider and use FBA. This membership provider will handle all SP related headers and initiate a Sharepoint authentication. Also, use Lazy sessions.

 

You can enable it to work with WebDAV by writing a persistent cookie within Sharepoint. It is a simple configuration change in the web.config file.

 

Plus with the new Shibboleth 2.1 SP, you can even use it with 64bit installations of Sharepoint 2007.

 

Thanks,

 

Moni Patil
TNS

[Caskey, Paul]

>You can enable it to work with WebDAV by writing a persistent cookie within Sharepoint. It is a simple >configuration change in the web.config file.

I'm not a Sharepoint person at all, but I would be very interested in knowing about the change in web.config for writing a persistent cookie. Can you provide additional detail?

Thanks!

[Moni Patil]

You should be using FBA.

1. When you change the Authentication Providers, make sure you check the
"Enable Office Integration" box checked.

2. There are two steps of doing this:
a. In web.config:
<authentication mode="Forms">
<forms loginUrl="Default.aspx" cookieless="UseDeviceProfile"
timeout="480" name=".ASPXAUTH" protection="All">
</forms>
</authentication>

b. If you are writing your custom login code, then simply call
the FormsAuthentication.SetAuthCookie(username,
setPersistentCookieBoolean)
This will set a persistent cookie based on what you
specified in the above web.config entry. This step is optional.

Thanks,

Moni Patil
TNS

-----Original Message-----
From: Caskey, Paul [mailto:pca...@utsystem.edu]

[Bucci, Debbie (NIH/CIT) [E]]

That's not the real issue... many ways to get through the front door ....

I may be simplifying it a bit but what it really comes down to ... in order to support all functions the SharePoint site must support SharePoint users and groups. There will be manual labor involved with this approach.

The LDAP just a poor man's way to extend federated access to not only sharepoint but ... as we have seen here ... to any other ldap based COTS product. Essentially gives the appearance of one large directory ... may ways to do ... call it what you want ... a *virutual directory * or use MS ADAM instance .... short term bridge until something better comes along ...

We probably could have done without all together - but this allowed us to port to other *LDAP* based apps instead of supporting for SharePoint alone.

Believe me - we tried to make it more complicated - but its not happening in this release.

________________________________________
From: Peter Williams [pwil...@rapattoni.com]
Sent: Wednesday, February 04, 2009 10:59 AM

[Caskey, Paul]

>
> 2. There are two steps of doing this:
> a. In web.config:
> <authentication mode="Forms">
> <forms loginUrl="Default.aspx" cookieless="UseDeviceProfile"
> timeout="480" name=".ASPXAUTH" protection="All">
> </forms>
> </authentication>
>
>
> b. If you are writing your custom login code, then
> simply call the FormsAuthentication.SetAuthCookie(username,
> setPersistentCookieBoolean)
> This will set a persistent cookie based on what
> you specified in the above web.config entry. This step is optional.
>

I don't control the login code, so I can't do (b.) above, only (a.) and, unfortunately, that did not fix the DAV stuff (being able to save an office file directly back into Sharepoint - File->Save is greyed out still).

Thanks for the info!

[Moni Patil]

I am not sure what your settings are. You may have to look into your
Membership Provider code or login code. It will be hard for me to tell
without understanding how your FBA implementation is laid out.

One thing you can validate is to look for the Sharepoint domain cookie
on your machine; this will tell you whether the cookie was indeed
persistent. If you don't see it, then it did not work and you may have
further testing/tweaks to perform before you can get it to work.

Also, make sure you have Office Integration enabled in the
Authentication Providers settings.

We are able to do Web Folders, Office 2003 integration, and Outlook
integration. Basically everything you would be able to do with NTLM
authentication. And everything is protected by Shibboleth while using
Forms-based authentication. The only caveat is that the Sharepoint login
cookie has to be valid for a long period, 8 hours in our case.

Thanks,

Moni Patil
TNS
-----Original Message-----

From: Caskey, Paul [mailto:pca...@utsystem.edu]

[Randy Wiemer]

Do your users have actual security principals in the AD hosting the
Sharepoint server?

That is, is there a one-to-one correspondence between the ID they used at
the IdP and an AD account?

Randy Wiemer
Oxford Computer Group

--------------------------------------------------
From: "Moni Patil" <Moni....@tns-global.com>
Sent: Thursday, February 05, 2009 8:47 AM

[Moni Patil]

We use Sharepoint groups that each user maps to. The users do have
actual AD principals, but we rely on the email address as the login id
for Sharepoint. So, the IdP has their principal name as the AD
principal, but Sharepoint uses the email address associated with that AD
principal.

Again, this should not matter when you use FBA. The source of
authentication can be anything and the login id can be anything you want
it to be.

I hope this answers your question.

[Randy Wiemer]

The part that is not clear to me is how the Office applications are able to
auth to Sharepoint with FBA.

I found the answer here:

http://simeonlobo.wordpress.com/2008/12/01/sharepoint-2007-forms-based-authentication-and-check-out/

Randy

--------------------------------------------------
From: "Moni Patil" <Moni....@tns-global.com>

Sent: Thursday, February 05, 2009 10:30 AM

[Michael A. Grady]

This is all, presumably, dependent on the browser's cookie cache
being shared with the Microsoft Office tools. That's true for IE if
you are running on a Windows box, is it true for any other
combination of browser/platform?

--
Michael A. Grady
Senior Technology Architect and Strategist
Office of the CIO, University of Illinois at Urbana-Champaign
2222 DCL, MC 256, 1304 W. Springfield Ave., Urbana, IL 61801
217.244.1253 phone, 217.244.4780 fax

[Moni Patil]

You need a Sharepoint Services-compatible application and IE 6.0 or
above.