Win2K3 R2 TechNet with Michael Murphy, Dig It?
March 1, 2006 | 3 Comments
Point of fact, no.
Yesterday I attended a Microsoft TechNet event with Michael Murphy. My interest in this specific TechNet was to learn what I could about Microsoft’s federated identity management plans.
The good news is that Active Directory Federation Services (ADFS) is now released. This package implements the WS-Federation standard for federated single sign on (SSO).
To Murphy’s credit he started the federated discussion with what I think is the perfect analogy, the drivers license. I’ll talk more about that at a later point, but I loved his quote: “Where is my drivers license for the Internet?”
It was when he started to be asked questions about their solution that his shallow knowledge and inexperience in this field became readily apparent. A gentleman asked the question, “How does this relate to the Liberty Alliance?” Murphy was not at all familiar with “Liberty” and basically dismissed the question. Unfortunately this would be like someone presenting about SQL Server and not being familiar with MySQL…
Anyway, another participant tried to get at what might allow LA and ADFS to interact, he asked: “Is this product SAML compliant?” Murphy said he’d never heard of SAML, and to him it sounded “like a camel named Sam.” Obviously this response was not useful to anyone…
At this point I piped up and asked about how ADFS exchanged authorization information with the service provider, the question was something like “how does it assert authorization and attribute information?” Murphy said it doesn’t. Unfortunately I knew this had to be untrue…
ADFS could not possibly be ONLY about authentication and completely ignore the authorization issue. I re-framed my question saying that attributes and authorizations were key to identity. He said they were not, this system addressed the authentication issue and attribute information was never communicated. Fear of sounding more like a dink led me to give up at this point…
I should have asked “What good is your drivers license without attributes for your age, sight restriction, etc.?” Maybe he would have “got it” then…
Moving on, Murphy demo’d how the interaction would occur using some virtual servers he had. The interface for managing and setting up these federated connections seemed pretty easy and intuitive.
When Murphy logged into the service provider interface in the demo, I immediately noticed that the newly created account already had a bunch of attributes. Most notably, a $500 spending limit.
I had to ask: “How does the service provider know this newly created user has a $500 spending limit?” Murphy stumbled with this, but threw out a blatantly off the cuff and incorrect response.
At this point a guy behind me asked “Can you scroll down?” This was it, clearly my fears for a half implemented federated system were really just due to a poor presenter. A pile of attributes, including custom defined ones including title were being listed in a textarea as the things being passed.
So anyway, ADFS has potential, but we’ll have to try it out for ourselves.
Stuff that intrigued me from other sections of the event:
Can we run Active Directory Application Mode (ADAM) centrally to manage our authorizations for all web-based applications? ‘Cause this would rock.
Windows Server Update Services (WSUS) could be useful for PSU…
Distributed File System (DFS) and the Branch Office Management seems partially implemented, not well thought out, and overall garbage.
The Cygwin replacement, or is there more to it?
Finally, did Michael Murphy learn his presentation style from Billy Mays?
Tags: "Active Directory Application Mode", "active directory federation services", "billy mays", "distributed file system", "liberty alliance", "michael murphy", "UNIX Interoperability Components", "windows server 2003 r2", "Windows Server Update Services", active directory, ad, adam, adfs, cygwin, dfs, federated identity management, identity management, microsoft, presentation, saml, technet, unix, windows, ws-federation, wsus
Emerging PKI
July 28, 2005 | 2 Comments
This week four of us attended the 2005 EDUCAUSE/Dartmouth PKI Deployment Summit. Our intention was to get a feel for the status of client-side PKI.
Before I get into that, here is a definition of PKI from the UK Department of Health: (just happened to be the clearest, most concise one I could find.)
“A public-key infrastructure (PKI) is the set of policies, people, processes, technology and services that make it possible to deploy and manage the use of public-key cryptography and digital certificates on a wide-scale.”
What about the client-side part? I can’t find a clean definition of this alone, but here’s my summary. Client-side PKI is the assignment of digital certificates to end users for the purpose of authentication without the need for usernames and passwords. An end user could then present their personal certificate as either a soft-copy or on a hardware token to gain access to systems and services they are authorized for. In general deployment of client-side PKI gives a much greater level of assurance (LOA) that the user is in fact who they claim to be.
With the vast number and variety of integrated and disparate systems in most higher education institutions, coupled with a need to be sure only appropriate users are gaining access to them, client-side PKI becomes an attractive technology.
One of the more interesting presentations was from Peter Alterman on behalf of the Federal Public Key Infrastructure Authority. He spoke at great length about LOA and what levels would allow you to map to other levels of access to federal services through the Federal Bridge. I assume there will eventually be a great number of services provided through the bride which will be of interest to higher ed, so institutions need to be aware of the hoops you may need to jump through to get certified. Keep in mind that usernames and passwords will only qualify you for minimal connectivity and services.
So why not roll out client-side PKI at your institutions as quickly as possible? Well… it is complex, the road is mostly unpaved, and it is hugely expensive. Each user needs to have a certificate assigned to them and renewed annually. The outright cost of these are usually $8-$15. Under the newly formed EDUCAUSE Identity Management Services Program (IMSP) a reduced price has been negotiated with VeriSign dropping the price to about $4 (or less depending on volume). Looking at a basic higher education institute with say 7000 users, that gives an annual price tag of $28,000. Put alumni in the same mix and that price gets worse. Then there is a cost associated with hardware tokens if you decide to use those. My understanding is that these run about $30 ($210,000 for 7000). The only way this could actually be funded would be to pass this cost along to the students in their technology fee and have departments budgets handle it for faulty and staff.
Many institutions are avoiding all of this by signing their own certificates. Of course this then prompts users about unknown signing authority which might cause calls to the help desk with confused users. This is the solution MIT, USC, and others have adopted.
There is another solution nearing availability, USHER, the US Higher Education Root. According to Neal McBurnett of Internet2, USHER will:
provide a basis for campuses to deploy signed documents, secure email, and other applications. Serving as both an infrastructure and an initiative, it will include a root (AKA trust anchor or certification authority) to identify campus roots [CA's], and recommended applications, tools and metadata. It will coordinate with the InCommon federation.
Assuming the USHER CA finds its way into the major browsers as an accepted signing authority, it will provide higher education with an affordable solution for digital certificates. USHER is a key player in multiple Internet2 initiatives including the InCommon Federation and Shibboleth. USHER does not yet seem to have its own web site, but is being coordinated by HEPKI-TAG. I believe USHER is the lynch pin for general deployment of PKI in higher education.
Tags: authentication, certificates, digital certificates, educause, federal bridge, federated identity management, federations, HEPKI-TAG, higher education, identity management, incommon, internet2, loa, middleware, pki, public key infrastructure, SSL, USHER, verisign