Think about it this way: If I show you my driver's license, would you give me the key to your house? Probably not; I don't belong in there. But *you* make the decision of who gets the key to your house, not the state that issued the license.
-- Tim
On 1/26/07, Cerebus cerebus2@gmail.com wrote:
On 1/25/07, Ron Teitelbaum Ron@usmedrec.com wrote:
For example, there are systems for Hospitals, Doctors, Patients, Labs and ER's. Each person has different access, but they also interact with different systems, so do you see a difference between coding authorization Permission on a Cert and using different CA's as the instrument that defines system access?
For a limited application--say, joining a WLAN--or a severely limited but broadly available level of access--like getting to the front page of a private web server--then mere possession of a certificate can be sufficient authorization. Anything beyond that and you want a separation between authN and authZ.
In your case, if your user populations interact a lot then there's a good case for having a single identity management system binding them all together as a community. Practically, this means a single PKI, or at least a group of cross-certified PKIs (how ever, cross certification has its own problem; path construction is a real PITA to do right all the time in a cross-cert environment, and then there's the whole namespace issue...).
So the cert provides identity proof, as it should. Once you know *who* the entity is, you need to define *what* the entity can do. Simply put, the problem is this: authN is forever, but authZ is temporary. An entity's access rights can change at any time, for any reason, from being fired to being promoted. If that data is bound *in* the cert, then you will have to revoke the cert whenever access rights change.
Revocation is *bad*; it grows the CRL. CRL growth causes problems.
The DoD PKI CRLs are over 140MB in the aggregate, and growing at a prodigious rate--and that's only from the administrative revocations (lost smartcards, name changes, rank changes, and affiliation changes mostly). If we had bound up access rights in the cert, the CRLs would be terabytes in size.
I understand the problems with coding system authorization and no CRL's, and I understand the maintenance issues with low level permissions but at a very high level I think it makes sense.
The separation of authN and authZ is one of the basic tenets of information assurance, right up there with the Principle of Least Privilege.
Start from base principles: Identify the communities and define how they interact.
If you're seriously building a PKI for your company I might be able to set you up with business contacts with people who've done this for a living. Let me know off-list.
-- Tim