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

[ Post a follow-up to this message ]