portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan Grant <Jan.Gr...@bristol.ac.uk>
Subject Sorry about delay: details on security 1.4 feedback.
Date Fri, 09 Aug 2002 16:56:26 GMT
Sorry about the delay folks - hectic week.

Basically here are explicit details regarding feedback to security-14
providers. Firstly, let me say what a huge leap forward it is. The
changes I'd like to see are to make explicit in the interfaces the
interaction between the portal and the provider, to lower the level of
knowledge about jetspeed internals in a provider, and to clarify some of
the semantics of the burden on providers (the last is basically informed
by trying to produce providers and looking at the standard turbine
implementation). This is also motivated by wanting providers that can
coordinate and compose other providers; and to shift code that would be
common to all implementations up into the jetspeed that wraps these
providers.


Changed interfaces for providers suggested (in brief) below with
comments. I've bundled up all of my comments and thoughts per interface
(from experience thus far) - so please feel free to reject the less
baked ideas if I'm missing the point.





public interface PortalAuthentication {

    JetspeedUser login(String username, String password)
        throws LoginException;

    JetspeedUser getAnonymousUser()
        throws LoginException;

    void logout(JetspeedUser user)
        throws LoginException;

}

The only change to the interface is to add the currently logged-in
JetspeedUser as a parameter. However, looking at the turbine
implementation, I'd also like to see context manipulation lifted out of
the provider and into the calling jetspeed framework.



public interface CredentialsManagement {

    void changePassword(JetspeedUser user,
                         String oldPassword,
                         String newPassword )
        throws JetspeedSecurityException;

    void forcePassword( JetspeedUser user,
                        String password,
                        JetspeedUser userContext )
        throws JetspeedSecurityException;


    String encryptPassword( String password )
        throws JetspeedSecurityException;

}

The only interface change is that the user attempting to force a
password change in the forcePassword call is passed explicitly as the
third parameter.
However, making the persistence semantics of the password changing calls
explicit (ie, the password is changed and the change persisted before
return; OR, the change is not required to be persisted and jetspeed
guarantees to call saveUser - I'm agnostic as to which) would be
appreciated.
I'm also not completely convinced of the utility of exposing the
password encryption to jetspeed - I'm a bit more of the opinion that
that's a private matter for the provider, but I've not tracked down all
useages of the last call yet.




public interface UserManagement extends CredentialsManagement {

    // Where calling user may be checked for permission, add userContext

    JetspeedUser getUser(Principal principal, JetspeedUser userContext)
        throws JetspeedSecurityException;

    Iterator getUsers(JetspeedUser userContext)
        throws JetspeedSecurityException;

    Iterator getUsers(String filter, JetspeedUser userContext)
        throws JetspeedSecurityException;

    void saveUser(JetspeedUser user, JetspeedUser userContext)
        throws JetspeedSecurityException;

    JetspeedUser addUser(Principal principal,
          JetspeedUser copyDefault /* or other parameters? */,
          JetspeedUser userContext)
        throws JetspeedSecurityException;

    void removeUser(Principal principal, JetspeedUser userContext)
        throws JetspeedSecurityException;

}


I'm not totally convinced that bundling this up with CredManagement is
necessary, but that's a niggle and I can live with that.

I've added the calling user from the context throughout; jetspeed should
provide this explicitly.

Secondly, I think the PSML management should be handled (via PSML
service) from the calling jetspeed framework, and the onus of psml
creation lifted from the provider (this is going by what
TurbineUserManagement does). Thus, remove that burden from addUser and
removeUser. I tend to view PSML and the rest of the user account as
separate.

Lastly, I'm not completely convinced about the way that addUser is used.
Currently a user is created by jetspeed, values set, passed in and
persisted. I'd rather shift all the burden of JetspeedUser object
creation into the provider at all points throughout jetspeed. I've
currently sketched a slightly different interface: a Princpal for the
new user is passed to addUser, together (optionally) with a "default"
account that forms the basis for this new account. addUser returns the
created user account (which can have further values set on it by the
user creation action). This is more motivated by attempts at using
multiple, coordinated providers.



public interface GroupManagement {

    Iterator getGroups(Principal principal, JetspeedUser userContext)
        throws JetspeedSecurityException;

    Iterator getGroups(JetspeedUser userContext)
        throws JetspeedSecurityException;

    // Like the next one to be modified akin to addUser above, too.
    void addGroup(Group group, JetspeedUser userContext)
        throws JetspeedSecurityException;

    void saveGroup(Group group, JetspeedUser userContext)
        throws JetspeedSecurityException;

    void removeGroup(String groupname, JetspeedUser userContext)
        throws JetspeedSecurityException;


    void joinGroup(String username, String groupname,
           JetspeedUser userContext)
        throws JetspeedSecurityException;

    void unjoinGroup(String username, String groupname,
           JetspeedUser userContext)
        throws JetspeedSecurityException;

    boolean inGroup(String username, String groupname,
           JetspeedUser userContext)
        throws JetspeedSecurityException;

    Group getGroup(String groupname, JetspeedUser userContext)
        throws JetspeedSecurityException;

}

Again, added explicit current user context to calls, provided by
jetspeed.

Could probably do with uniformity of approach (do you use Strings or
Principals to identify users and groups?) - I've not tidued up every
call.

The same comments about addGroup apply as addUser.

I'd like to see PSML creation burden moved into jetspeed, not the
provider.

Exactly the same comments apply to the RoleManagement interface, so I
don't repeat them here.



public interface PermissionManagement {

    Iterator getPermissions(String rolename, JetspeedUser userContext)
        throws JetspeedSecurityException;

    Iterator getPermissions(JetspeedUser userContext)
        throws JetspeedSecurityException;

    void addPermission(Permission permission, JetspeedUser userContext)
        throws JetspeedSecurityException;

    void savePermission(Permission permission, JetspeedUser userContext)
        throws JetspeedSecurityException;

    void removePermission(String permissionName,
           JetspeedUser userContext, boolean cascade)
        throws JetspeedSecurityException;

    void grantPermission(String roleName, String permissionName,
            JetspeedUser userContext)
        throws JetspeedSecurityException;

    void revokePermission(String roleName, String permissionName,
            JetspeedUser userContext)
        throws JetspeedSecurityException;

    boolean hasPermission(String roleName, String permissionName,
            JetspeedUser userContext)
        throws JetspeedSecurityException;

    Permission getPermission(String permissionName,
            JetspeedUser userContext)
        throws JetspeedSecurityException;

}

Not much to say here, except that the user is passed explicitly. I'm
also not completely sure what the purpose of the cascade deletion of
roles is (I think the provider, not jetspeed, ought to decide that. At
the least, for multiple providers, the cascade flag may be different
with each and so should be explicitly passed).

For addPermission, see the comments pertaining to addUser etc. (not
reflected in the interface above)



The PortalAccessController is much more jetspeed-specific than the other
provider interfaces; I've yet to get much in the way of implementation
experience of providing a new implementation. It looks OK as it
currently stands, on a first pass.



Many thanks for taking the time to get this far! I'd appreciate your
comments.

Cheers,
jan


-- 
jan grant, ILRT, University of Bristol. http://www.ilrt.bris.ac.uk/
Tel +44(0)117 9287088 Fax +44 (0)117 9287112 RFC822 jan.grant@bris.ac.uk
I am now available for general use under a modified BSD licence.





--
To unsubscribe, e-mail:   <mailto:jetspeed-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:jetspeed-dev-help@jakarta.apache.org>


Mime
View raw message