Blog changes coming

I’ve just finished a process of manually merging the two blogs hosted under viewpoint into a single one that can be bundled up for import into the coming sharepoint service.

I’ve re-categorized several posts, and moved files and other content too.

Posts from David Zazzo lost their authorship (he’s not here to move them).

Most comments were moved, but thrown into the post body.

The ms-collab blog got the older winauth content, and then when we move to the production service that blog will be renamed to more closely represent the folks doing the actual writing.

We’re also pondering a couple other changes, including changing from basic authentication over https to Windows Integrated over http. This is largely because many viewers don’t trust the UW certificate authority (CA) which issued the certificate for this site.

We originally ended up at basic over https because of a couple reasons, now all gone:

  • Some viewers had browser/platform combos which couldn’t do Kerberos or NTLMv2, but wanted to post comments or configure alerts (the only things that require login)
  • We didn’t want to allow anonymous comments, because we got spam
  • Doing basic auth without ssl breaks UW Computing policy

With the NETID domain allowing NTLMv1, we’ve moved to a different place since an overwhelming number of browser/platform combos do support that.

Assuming we move forward on this change, we’d likely regain https access (via a new hostname) when we move to the coming Sharepoint service, likely with a Thawte issued certificate.

Sharepoint Knowledge Network

There’s quite a few social networking websites out there. You’ve heard of them, and may even be using them. They give individuals a way to put information about themselves out in front of others, and allow individuals to connect with people that might share a common interest or a needed skill.

However, none of them really gives you a scope which easily integrates with other UW folks, whereas using the coming UW Sharepoint service will give you that.

And this is one of many reasons why moving your local Sharepoint service to the central UW Sharepoint service makes a lot of sense.

If you will, imagine a future where all the UW IT staff have populated their Sharepoint profile with their responsibilities, skills, past projects, and interests. Then, imagine how as an IT staff member you can find other IT staff who share your interest in a technology. Or imagine how in the midst of an issue, when established channels seem to be failing, how you can identify who the staff who have responsibility for a particular service are. Or imagine how IT managers might have a better picture of what their staff are responsible for, and which staff have skills that qualify them for special project work.

I’m sure we can all imagine other scenarios that could leverage this kind of information.

But it’s important to note that these scenarios are only possible with data collected from the relevant body of people (and that the data is accurate). The more data collected the better the picture becomes.

Federated Sharepoint

Can you do that!? Yes, and in fact, the University of Missouri has a working demo of this that I’ve seen (and in fact, I have 10GB of virtual images of that demo environment). In terms of the coming Sharepoint service offer, it isn’t immediately clear today whether we’ll be able to offer federated authentication at the time of the initial offer, but I do think it’s a feature we need to support.

There are two general use cases for using federated authentication with Sharepoint:

a) All your collaborators have a UW NetID, but for some reason their OS and browser can’t do Windows Integrated authentication (Kerberos, NTLMv2, or NTLMv1).
b) All your collaborators don’t have a UW NetID, but they have credentials elsewhere via either an ADFS or Shibboleth infrastructure.

Most of this blog post will focus on b), but let’s talk just a bit about a) first.

An overwhelming majority of browsers and operating systems do permit Windows Integrated authentication of some flavor, so there isn’t a large demand for this, however, it is an option for that small set of clients.

In this scenario, you’d permit pubcookie authentication via the UW’s Shibboleth IdP. IdP is the terminology for the server which issues the authentication token in this technology.

For either a) or b) you need to have a second web application which has another authentication provider than Windows Integrated. That other web application can point at the

same site content, but because of the security details underneath both federation technologies, you are required to have a different URL if you have access to any given site

via both Windows Integrated and a federated authentication provider. Some of this is noted here, in this ADFS and MOSS configuration link, http://technet2.microsoft.com/Office/en-us/library/61799f9a-da01-4c11-b930-52e5114324451033.mspx?mfr=true

For either a) or b) there are side-effects/limitations/broken features. For example, the Office document library integration breaks. Which brings me to the second of many external links, Unsupported SharePoint features with ADFS, http://go.microsoft.com/fwlink/?LinkId=58576. And yes, that list is relevant for both a) and b). So generally speaking, if

you can help it, you want to do Windows Integrated authentication. And while I’m back on that topic, I should also mention that those clients which can’t do Windows Integrated auth have another option which is do basic auth together with ssl.

Moving onto b), we’ll get a bit into the architecture, and then later on, I’ll talk about how there are actually two possible solutions for a) and b) (which makes talking about this

already complex topic much more complicated).

So … for a general overview of Shibboleth and ADFS, there are a number of good online resources:
Understanding Shibboleth, https://spaces.internet2.edu/display/SHIB/UnderstandingShibboleth
ADFS Design Guide, http://technet2.microsoft.com/windowsserver/en/library/a6635040-3121-47ce-a819-f73c89dafc571033.mspx?mfr=true

Doing the interoperability between ADFS and Shibboleth requires installing the Shibboleth extension for ADFS, https://spaces.internet2.edu/display/SHIB/ShibADFS, on your IdP, and on every IdP you’d like to accept authentication claims from.

This link has probably the best information available anywhere about the actual interoperability between ADFS and SHibboleth, Shibboleth and ADFS Interoperability

Whitepaper, http://www.oxfordcomputergroup.com/ocg_/images/resources/ADFS%20White%20Paper%2002-07.pdf.

From a quick overview of the architecture components involved, let’s talk about an imaginary use case. Say you’ve got a collaborative group that includes folks from Stanford and the UW.

The Stanford folks would go to the Sharepoint site, and the ADFS Web Agent would redirect them to authenticate with their Shibboleth IdP (using their local webauth sso provider) and present that claim to a UW ADFS-R server. That server would take the claims, perform any translations specified in a trust agreement, and issue a new set of claims to present to the Sharepoint server which has the ADFS Web Agent installed. That ADFS Web Agent takes those claims, and translates them to the Sharepoint security model.

Both of these links talk about this last step:
http://blogs.msdn.com/sharepoint/archive/2007/02/15/how-to-use-adfs-to-turn-moss-2007-into-a-claims-aware-application.aspx
http://blogs.msdn.com/sharepoint/archive/2007/10/11/a-script-to-configure-sharepoint-to-use-adfs-for-authentication.aspx

Now the description I’ve just shared is one of two possible solutions for b) (and to some extent a)). The other solution drops ADFS from the mix. That one goes like this:

The Stanford folks would go to the Sharepoint site, and the Shibboleth agent would redirect them to authenticate with their Shibboleth IdP (using their local webauth sso provider) and present that claim to our Shibboleth SP server. That server would take the claims, perform any translations specified in a trust agreement, and issue a new set of claims to present to the Sharepoint server which has the Windows Shibboleth agent on it. The Windows Shibboleth agent takes those claims, and pass them to a custom asp.net membership provider which translates them to the Sharepoint security model.

There is a vendor which has something that I think is (or is close to) the custom asp.net membership provider needed. You can read more about it at http://www.9starresearch.com/activesharefs.html.

I suspect the solution which includes ADFS is going to be preferable, but that’s still to be fully considered.

More with Forms in Sharepoint

I’ve come across a variety of Forms oriented content which I think is useful. I’ve split it into several sections, starting with the more basic stuff first.

Basic Forms Information

The Office team has:

On the flip side of that last item, here’s a blog entry detailing the infopath functionality lost when using the browser-compatible feature.

Doing stuff with the Forms Data

When it comes to using the data submitted via your form, there are many options:

  • Associate your form content type with a custom list, have the submit action be directed at this sharepoint list, and make the relevant input field be the columns of that custom list.
  • Associate your form content type with a list or document library, have the submit action be directed at this sharepoint list, and create a view with the relevant input fields as the columns of that view.
  • Associate your form content type with a list or document library, have the submit action be directed at an email address, and plan to use Outlook 2007 to work with the forms. For more on this, see http://office.microsoft.com/en-us/infopath/HA102068981033.aspx and http://blogs.msdn.com/tudort/archive/2006/02/22/536800.aspx.
  • Associate your form content type with a list or document library, have the submit action be directed at web service, and use the core system.dataset type within that web service to work with the data.
  • Associate your form content type with a list or document library, have the submit action be directed at a database (other than Sharepoint), and manage the data via that database.

So the key configuration point here is it all depends on how you configure the submit action within that InfoPath form. You might recall the example I blogged about where I choose to submit form data to a sharepoint list, however, I might just as easily have chosen to submit that data elsewhere, if it made processing the data easier–or if the privacy of the data necessitated that it be stored specially.

On the infopath team blog, there’s a good post on data connections from Forms which outlines the database options.

For those of you who might like the target to be an Access database (why not move to SQL?), there’s another good post on Access specific data connections from Forms.

If you do submit the form data to a sharepoint list, you can programmatically retrieve that data and do what you want with it.

Advanced Forms Info

For developer-types, there are a couple folks who have figured out how to embed a form within a webpart, so that you might have a form be part of a sharepoint page:

This might be highly useful in the context of a departmental web portal where you want to raise the visibility of a form by embedding it on the front of your department’s web page.

Earlier I mentioned the option of targetting a web service with your form submissions. Here’s more detail on how to access a web service from a browser-enabled form.

You can also populate forms with data already in Sharepoint or some other database by using a data connection within the infopath form. Imagine an text input field which would have unnormalized input unless you restricted the possible input to an existing list of normalized values. See here:
http://blogs.msdn.com/infopath/archive/2007/01/15/populating-form-data-from-sharepoint-list-views.aspx.

You might also imagine an infopath form which generates calendar events in a shared sharepoint calendar webpart. Imagine a process for reserving a shared resource …

Free Self-Training Resource

Finally, if you’d like to get yourself up to speed on all the InfoPath functionality, see this list of free training labs live on MSDN.