Re: [Fed-Talk] Re: "Authentication" < > "SSO"
Re: [Fed-Talk] Re: "Authentication" < > "SSO"
- Subject: Re: [Fed-Talk] Re: "Authentication" < > "SSO"
- From: Paul Nelson <email@hidden>
- Date: Mon, 29 Dec 2008 14:38:09 -0600
- Thread-topic: [Fed-Talk] Re: "Authentication" < > "SSO"
>
>> I emphasized *Authentication* .... same I have said for a couple
>> years now...
>>
>> "Authentication" < > "SSO" (for those not familiar, SSO
>> is Single Sign-On)
>
> And it's as much splitting hairs now as it was then. :)
Terminology is such a pain. Experts have been telling us that there is a
difference between Authentication and Authorization. They make a very good
argument about keeping these ideas separate. However, the two always go
hand in hand on computer systems because you can't do anything useful just
by "authenticating" someone.
When I go through airport security I have to present my ID card AND my
boarding pass. My ID identifies me, but my boarding pass provides my
authorization. Showing my ID without the intention of going into the secure
area would just be silly.
The way that Apple splits authentication from authorization for smart card
users has some severe limitations:
A) The directory service is not able to enforce its own rules, policies and
procedures for authorization because it never gets the chance to do so.
These are all handled by the login window and its plug-ins.
B) People deploying Macs have to assume that the Macintosh security software
meets all the applicable requirements of the enterprise. In other words, it
is not a broken implementation. Does it properly validate all certificates
being used? Has Apple's implementation been awarded any certification from
a trusted authority (like FIPS or JITC)?
C) Is Apple's implementation of authorization policy adequate for the
enterprise? For example, can it enforce policies that define what happens
when a smart card is removed from the system? In other words, does it
gracefully handle deauthorization?
D) Can you manage the Mac platform without using passwords at all? What
about rights elevation using a smart card?
I want to point out that PKINIT is not the equivalent of proving that a PIN
unlocks a smart card. Even if you simply throw away the resulting Kerberos
ticket. With PKINIT, you are using your enterprise equipment for evaluating
authentication. Without it, you are simply assuming that the local
processing implements an equivalent method. If you assumed this, you would
be wrong.
When I wrote the PKINIT that is part of Thursby's ADmitMac for CAC product,
I quickly learned that a lot more work was needed. We had our
implementation certified by JITC. We added support for rights elevation.
We added support for OCSP responders and a number of other things.
Having a PKINIT implementation is not the same as "working with Active
Directory". Most of the installed base of Active Directory implements an
old, non-standard PKINIT. You have to upgrade to Windows 2008 to have an
Active Directory that conforms to industry PKINIT standards. Apple does
have an implementation of PKINIT in Leopard. However, it is not useful for
Active Directory smart card authentication. The moral is, don't ask your
vendor for PKINIT. Instead, ask them for what you really need: two factor
single sign on using a government issued smart card. Then ask them for all
the other things you MUST have to implement authorization for your
enterprise.
Paul Nelson
Thursby Software Systems, Inc.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Fed-talk mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden