Use of private and public credentials in JAAS

Question

In an interview interviewer asked me why you need private credentials in JAAS?
We can access both public credentials and private credentials like :

Set<Object> privateCredentials = subject.getPrivateCredentials();
Set<Object> publicCredentials = subject.getPublicCredentials();

Both ( privateCredentials and publicCredentials ) are accessible and the way of access are same.
So, what is the significance for tow types of credentials?

Carrelli

Is this a general question about the role of private keys in PKI cryptography? – Symphonize

Answer 1

From "Java and Internet Security" book by Theodore Shrader, Bruce A. Rich, Anthony J. Nadalin:

With somewhat more controversy, the JAAS designers concluded that Principals may have some sort of proof of identity that they need to be able to provide at a moment’s notice, and these proofs of identity may include sensitive information, so a set of public credentials and a set of private credentials were also added to Subject. Since the content of a credential may vary widely across authentication mechanisms, from a simple password to a fingerprint (to infinity and beyondl), the type of a credential was simply left as java.lang.Obiect. Relationships between Principals and credentials, if any, were left as an exercise for the implementer of the particular Principal class (or more likely, the particular LoginModule class). From a JAAS perspective, the only difference between private and public credentials is that a particular javax.security.auth.AuthPermission is required for access to the set of private credentials.

Reuven

Answer 2

Well you don't really need them at all in general. I have a fairly large JAAS system with about 7 LoginModules and I don't use private credentials at all. You would use them if for example you wanted to store the user's password or private key for retrieval by other parts of the system, but there's nothing intrinsic about needing to do that, it depends entirely on how you design your system. My attitude is that the password is in LDAP and that's where it stays, and I don't have users with private keys.

However when you do need them, you need them to be separate from the public credentials, because they're private, not public, innit? and indeed they can be further protected by requiring PrivateCredentialPermissions to access them.

Paleogeography

Answer 3

From the JAAS Reference Guide:

In order to iterate through a Set of private credentials, you need a javax.security.auth.PrivateCredentialPermission to access each credential. See the PrivateCredentialPermission API documentation for further information.

Bebeeru

Why was this downvoted? It's the most concise of all the answers here, AFAICS. It also perfectly sensible - accessibility to private credentials can be restricted, which seems to be their whole point. – Lordinwaiting

I didn't downvote, but this doesn't answer the question. He isn't asking about the API and permissions, he is asking why we need private credentials in JAAS at all. – Paleogeography

Answer 4

From my understanding of JAAS (and more understanding of general SW design principals)
A Subject is an entity represents a source of request , for example a user , and since JAAS is about providing an abstract API for various authorization/authentication mechanisms, you can also look at Subject as some sort of abstraction.

I'm using JAAS with Krb5LoginModule and for example, in our case, principal represents the user details (username + realm - i.e - "[email protected]").
The user might have a set of private and public credentials depending on the underlying cryptographic mechanism (I hope I'm using a correct term here) - for example, if asymmetric key cryptography is used, you can use the getPublicCrendetials in order to get information on the public keys.
getPrivateCredentials will hold a set of a private keys, and you will probably need privileges in order to get that list.
Although I never tried it before, maybe you can use the getPrivateCredentials in order to get a private key and use it for digital signing?

I can tell you that I used these methods in order to obtain the kerberos ticket, and get information on its validity (expiration time). I hope that this gave you some more idea on why this division was made.

Hunker

Answer 5

Public credentials can be freely exposed and passed around on the subject. Examples:

• certificate
• public key

Private credentials are secrets. Since Subject objects can have a wide audience, these need to be hidden from access by "outsiders". The API provides restrictions for accessing the private credentials of a Subject, which are detailed in other answers. Examples:

• password
• private key

Schrader