UWWI User displayName Update

About 2 years ago, I wrote about how the UWWI user displayName provisioning works. Last Friday, there was a slight change, and this post is to amend that prior post with the new behavior.

UWWI user displayNames are used most prominently by UW Exchange, but are also used by other applications that leverage UWWI, such as UW Sharepoint.

So the change itself is small, but it potentially affects quite a few UWWI users. In specific, any shared UW NetID can be affected by this change. Back in 2009, I wrote:

“Upon provisioning, our account creation agent, fuzzy_kiwi, does some complicated name parsing logic similar to what I’ll describe below. For uw netids where it doesn’t find a PDS entry, or where it isn’t allowed to publish the name, it stamps the uwnetid value on the name attributes. And for some uw netids, that initial value is where things end.”

Until last Friday, that was the end of the story for all shared UW NetIDs. The only way they got a displayName value was via our account provisioning/password agent, and the only displayName value they could have was the uwnetid value.

The account provisioning & password agent now uses different logic to determine the displayName it should populate for shared UW NetIDs. For shared UW NetIDs, it instead uses the PDS displayName value with some minor manipulation to improve the casing.

What is the PDS displayName attribute?

Well, here are some factoids about the PDS displayName attribute:

  • It generally isn’t used very widely (because there are many other name attributes which generally have more interesting data)All values in it are upper case
  • There isn’t a self-service method to modify the PDS displayName attribute, but the administrators for a given shared UW NetID can call the UW-IT Help Desk to get it modified
  • The source for PDS displayName attribute value for shared UW NetIDs comes from the UW NetID system
  • The source for PDS displayName attribute value for other UW NetIDs varies (and is generally what is considered the “official” source of data)

Some of these factoids about the PDS displayName attribute may change (perhaps radically) in the future, as it may be the attribute used to deploy the UW NetID displayName solution I talked about 2 years ago.

So the UWWI user displayName for shared UW NetIDS will now be upper case?

No. We do a slight modification to the data to make it more readable/usable. We lowercase it all, and upper case only the first character in each “word” in the data. So generally, it looks pretty good, but there are some cases where the first character of a “word” is a special character, and then it doesn’t look quite right.

Example UWWI user displayNames that might come out of this are:

  • “Brian D. Arkills”
  • “Arts Sciences Deans Office”
  • “Temporary Patron”
  • “Simpson, Bart”
  • “Brian Arkills ‘admin'”

Note that this logic doesn’t attempt to re-order the data for consistency, so “lastname, firstname” isn’t re-ordered to “firstname lastname”. But keep in mind that generally Shared UW NetIDs don’t have a person’s name on them, but instead have a department’s name or something similar.

So when would a UWWI user that is a shared UW NetID benefit from this new displayName provisioning functionality?

Here are the ways this new logic can be triggered:

  • UW NetID password set (usually happens after UW NetID creation)
  • UW NetID password change
  • UW NetID rename (a rename isn’t recommended unless you can’t avoid it)

And that’s it. This logic change is only implemented in the account/password provisioning agent, not in ILM.

Earlier I mentioned the UW NetID displayName solution that I revealed 2 years ago. That solution isn’t dead, it just hasn’t been prioritized. And we still see that solution as simplifying the complexity, providing self-service management for all UW NetIDs, and most importantly putting control into your hands.

ADFS 2.0 Smorgasbord

Over the past several months I’ve seen 4 or 5 presentations on ADFS2. And of course, ADFS2 was released to the web on 5/5/2010. And as announced previously on this blog, we’re actively in a partnership with Microsoft around Shib interop with ADFS2.

So it’s time for all this material to get into a blog post. 🙂

First, see http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=118c3588-9070-426a-b655-6cec0a92c10b&utm_source=feedburner&utm_medium=feed&utm_campaign=Feed:%20MicrosoftDownloadCenter%20(Microsoft%20Download%20Center) for the ADFS2 download.

Second, the terminology is important to understand, so here’s a decoder ring. I’ve put in bold the terms I think make the most sense to use.

Security Token Service (STS) = Identity Provider (IdP) = Issuer = the server that verifies identity, adds claims, and issues a SAML token.

Claims = Attributes = Assertions = information about the identity associated with the login token which the token issuer claims/asserts are true.

Relying Party (RP) = Service Provider (SP) = Consumer = a server which wants to consume a federation token, possibly using claims in that token for authorization decisions.

One really important concept to understand about the federation IdP/STS role server is that it is *all* about issuing a token in a standardized form, which in both the Shibboleth and ADFS (either version) cases is a SAML 1.1 token. It takes some form of authentication credentials and “transforms” those provided credentials into a SAML token which you can use in a standardized way. So if you are a Math or Coding geek (as I am) you might think of the federation IdP/STS server as a function that transforms non-standard input into a standardized output. Or if you’ve travelled at all, you might think of the IdP/STS as the money exchange you have to visit each time you go from one country to another. You have currency–it’s just that no one accepts the currency you have, and so you need to get the currency that is accepted locally.

Another really important concept to understand is that the Consumer only knows about a single Issuer, or put another way: the Consumer only trusts a single Issuer. I talk about the federated access dance down below.

Third, you might be wondering a lot of various questions.

Why federate? Why not use Windows Integrated Authentication?
Common answers are:

  • you’ve got stuff to protect that isn’t Windows based
  • you need to give folks outside the UW access
  • you are porting your app to the cloud

Why use ADFS when we’ve already got Shibboleth?
The answer there is much more complex. As I’ve already said previously, ADFS2 has interop features with Shib, so stuff that uses an ADFS2 Security Token Service (STS)–which means the same thing as an IdP in Shibboleth-speak–can accept SAML 1.1 login tokens from a Shib IdP.

But there is more to federation than just issuing login tokens. You also need to accept federated login tokens, i.e. the role that Shib calls a Service Provider (SP) and ADFS calls a Relying Party (RP). And assuming you are accepting login tokens from elsewhere, you also need to perform token transformation or claims transformation. Claims transformation is the process of taking claims issued by another authority and tranforming them to mean something within your environment, typically for use in authorization or to populate a user’s details in an application.

Something like Sharepoint 2010 has built-in support for ADFS2, meaning that as a RP, it understands ADFS2 issued tokens and can leverage ADFS2 claims transformations. As I understand it, *only* using Shibboleth to federate Sharepoint 2010 means you’d need to write code for some custom claims transformations.

So the more appropriate question is can we leverage Shibboleth as the point of token issuance along with ADFS2 for the claims transformation? And the answer to that is yes. I’ve seen several demos of this working.

The trick then becomes figuring out whether you also want to be able to use ADFS2 for token issuance.

Why might you want to use ADFS2 for token issuance on top of Shibboleth?

Well, your Windows login token, i.e. the one you get when you interactively login to your computer via a Windows domain account, can be used to automatically get an ADFS2 login token without throwing yet another authentication prompt in the user’s face. With the advent of UWWI delegated OUs, you might believe that reducing the number of logins is desirable and attainable for some population. Whether there is enough demand there isn’t clear to me yet.

However, if it was something we wanted, then we’d next need to deploy a custom WAYF on the ADFS2 server.

What’s WAYF?

WAYF stands for Where Are You From? WAYF is the mechanism where the client chooses what Issuer they’d like to authenticate with. You’ve probably used the WAYF associated with InCommon to choose that you are from the UW and want to login against the UW Shibboleth IdP. In this case, we’d need to have a WAYF that gave 2 options:

  • UW Shibboleth (i.e. Weblogin)
  • UW ADFS (i.e. UWWI).

Moving on from high-level stuff, let’s talk more about details.

The federated access dance is something like this:
a) client goes to Consumer (a website)
b) Consumer asks client for a valid token
c) Client tell Consumer it doesn’t have a token
d) Consumer sends a 302 redirect to client to talk it its Issuer (Issuer A)
e) Consumer hits the WAYF at Issuer A
f) Consumer chooses something from WAYF and gets sent a 302 redirect to their Issuer (Issuer B)
g) Client hits Issuer B, provides credentials
h) Client is issued a SAML token by their Issuer (Issuer B), gets sent a post redirect to the original Issuer (Issuer A)
i) Client hits the original Issuer (Issuer A), which takes the SAML token from Issuer A, and transforms it, issuing a new SAML token and sending a post redirect to the Consumer. The transform may drop some claims and add some new claims, all based on business rules specific to the trust between Issuer A and Issuer B.
j) Client hits the Consumer and presents a valid token
k) Consumer evaluates claims in token, and decides what resources the client has access to. In some cases (e.g. Sharepoint 2010), it might have its own “internal” STS that is used across a farm of resources, and issue yet another token to the client (sending us back to step i).

ADFSv2 supports the following possible authentication sources:

  • Active Directory
  • a “chained” SAML 1.1 token, i.e. a token issued by another federation server

If you have a different authN source (say MIT KDC) or to accept some other kind of token, you no longer can use the “out of the box” ADFS product, but need to build your own STS using the Windows Identity Framework SDK. Many online examples show you how to do this in a step-by-step approach, but this is not for the faint of heart. This point is important to keep in mind, because sometimes when people say they are using ADFS for some interop scenario, they aren’t–they are using a custom STS that is really just a distant cousin of ADFS.

ADFSv2 supports the following possible directory sources for claims:

  • Active Directory
  • MS AD Lightweight Directory Services (LDS)
  • SQL
  • LDAP directory which uses Windows integrated

Documentation updates

Over the past month or two, there have been a couple of minor documentation updates.
Most notably, we’ve taken over ownership of the “Activating Windows on Campus” documentation, and brought it up to date. Back in the Vista release timeframe we wrote that document and UWare chose to host it within their web directory. The UWWI service line includes the campus KMS service, so it was a natural progression that moving this document so it could be maintained over time was for the best. You can find that document via a link on the UWare site, linked from the UWWI document index http://www.netid.washington.edu/documentation/default.aspx, or directly athttp://www.netid.washington.edu/documentation/activatingWindows.aspx.

The UWWI Architecture Guide has received a few minor updates mostly around documenting permissions.

http://www.netid.washington.edu/documentation/archGuide.aspx#visibility now lists which managed UWWI user attributes are visible by anyone with a UW NetID and http://www.netid.washington.edu/documentation/managedUserAttributes.aspx now includes that information as well.

http://www.netid.washington.edu/documentation/archGuide.aspx#selfWrite now talks a little about how some UWWI user attributes (managed or unmanaged) have permissions which allow the user themselves to updated them. A new document, http://www.netid.washington.edu/documentation/selfWriteUserAttributes.aspx, lists those attributes.

Looking farther back in time, last year we received quite a few requests to integrate applications with UWWI for authentication and authorization. Out of that flurry of requests, we wrote ‘How to use UWWI for LDAP Authentication’ at http://www.netid.washington.edu/documentation/ldapConfig.aspx.

I expect that we’ll be adding quite a few new documents as we extend UWWI to support the features from the Delegated OUs project, so stay tuned for more updates.