Great Mac Documentation: Flashing Icons and SSL
July 21, 2006 | 3 Comments
On two occassions this week I went looking for documentation on how to do “stuff” on my Mac. I was pleasantly surprised at the quality of documentation I found from Apple with simple Google search strings.
I wanted to setup SSL on the web server that runs on my OS X.4 desktop. So, I searched for “mac ssl web server”. This turned up Using mod_ssl on Mac OS X, which is a detailed guide which acts as a cookbook for getting this up and running using the infrastructure already in place on your Mac.
Later I was helping a co-worker who was experiencing difficulty with starting up his Mac. The symptom was a flashing globe. So, again a Google search: “mac flashing globe”. This turned up another article straight from Apple, Mac OS: Flashing Globe When Computer Turns On. Again the document immediately explained that the network disk must have been mistakenly selected for startup. The solution: be patient, it’ll eventually time out and switch back. Perfect!
Of course, after being patient, we got a new symptom… The flashing globe was replaced with a flashing question mark. Back to Google for a final run: “mac flashing question mark”. This time the Apple document was second in the list, but equally helpful. It also told us to be patient, but listed a bunch of steps to take if this did not work out.
All I can say is that Google combined with the really good Apple Mac documentation is a powerful combination. I’m under the impression that a monkey with an internet connection could support a pile of Macs and still have time to screw around.
Tags: apple, documentation, flashing, flashing globe, flashing question mark, globe, google, google search, mac, macintosh, question mark, SSL, support, web, web server
Mishmash of Acronyms
August 29, 2005 | 5 Comments
While reading technical documentation today Jon and I busted a gut when we read:
“You can set the LDAP authentication process to use Single Socket Layer (SSL).”
I assume this is some tech writers confusion between Secure Socket Layer (SSL) and Single Sign-On (SSO).
Tags: definition, secure socket layer, single sign on, single socket layer, SSL, sso
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