[TRIPLESEC] How is the SafehausLoginModule supposed to use kerberos? ... and other questions

[David Jencks <da...@yahoo.com>]

I'm working on an integration test for the safehaus login module and  
I'm confused by how it is using kerberos.

Please keep in mind that I'm a kerberos beginner :-)

Also there appear to me to be a lot of bugs in the existing code....  
such as bindAs not actually using the authentication info supplied.

Basically, it looks to me as if it would make more sense to have 3  
login modules, and you can use 1 or 2 in a login configuration:

- one-factor kerberos module
- two-factor kerberos module
- triplesec module.

If you want kerberos, you'd pick a kerberos module, which would  
presumably wrap the one from the jvm is is done inside the safehaus lm.
The triplesec lm would run after the kerberos (if present) and just  
check that the credentials allow you to look up the user, and also  
get the SafehausPrincipal into the Subject.

This would let you run without kerberos if you wanted.

Can anyone explain why the kerberos is required and embedded into the  
SafehausLoginModule?


----

In a couple of related issues, I think that

-- the realm and application policy factory should come from Options,  
not CallbackHandlers.  Realm is easy since it's a string and even the  
simpleminded sun LoginConfiguration can supply it.  I guess allowing  
a policy callback handler is a good idea for those environments  
relying on the sun login configuration, but for those with more  
sophisticated environments (geronimo :-) it will be a lot more  
convenient to use an option.

-- AFAICT users have credentials, policyIds don't.  Currently we're  
trying to log in as policyIds rather than users.  Furthermore, a user  
can have many policyIds, but each policyId can have only one user.    
I'm not comfortable with this model.   I think that it makes more  
sense for each user to have one policyId, but a lot of users can use  
the same policyId.  The reason for this might be based on my jacc  
biases.  In jacc, the j2ee application specifies the roles and the  
role>> permission maps, and you are sort of expected to redeploy the  
application if you want to change them.  (I'm looking forward to  
using triplesec to get around this, but it's worth keeping in mind  
anyway).  Anyway, by deploying an app you will get a bunch of roles  
defined with permissions associated to them.  I'd expect that the  
next thing the security administrator would do would be to figure out  
the kinds of users they expect and set up profiles for them,  
basically by having a set of roles with a few added grants or  
denials.  Then when a user shows up they can just be assigned to a   
profile, unless they need special treatment.

Furthermore, when you log into an application you usually supply a  
username and password.  If each user has one profileId then this is  
all you need (password being possibly replaced by more/other  
credentials).  Otherwise we need to either ask for profileId and  
username or ask for profileId and navigate back to userId.  This  
seems awkward and unusual to me.

There might be good reasons for how it's set up now... if there are I  
hope to hear them :-)

----

I've previously mentioned that I need a principal to cover more than  
one "application" (which I proposed calling "context").  I think that  
the "realm" idea is what I need to organize the application/ 
contexts.  I'm planning to introduce a "RealmPolicyFactory" that gets  
you a profile given a profileId and a contextId/applicationId.  This  
should be pretty much all that's needed to make the SafehausPrincipal  
usable in the jacc prototype I whipped up a while back.

many thanks,
david jencks