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 Security 1.4: more implement[eo]r feedback on provider APIs
Date Mon, 05 Aug 2002 13:49:23 GMT
I recently raised the issue that the security provider APIs don't supply
all of the context explicitly as part of their method signatures (eg,
logout() should be logout(User) )

This is proving to be a bit more than an aesthetic issue.

[background]
The project I'm involved in is using Jetspeed as a framework for a bunch
of services for UK HE. One of our requirements is that we support a
number of different authentication mechanisms; these may potentially be
selected dynamically.

The approach we're taking is to write each mechanism as a plugin
provider. The plan is to use an overarching multiplexer that can
delegate to other, simpler providers based on runtime criteria.

However, the current interface is full of implicit points where the
security provider API is circumvented by direct calls to the underlying
rundata, for instance:

[this is from UserManagement.java]

    /**
     * Retrieves a <code>JetspeedUser</code> given the primary principle.
     * The principal can be any valid Jetspeed Security Principal:
     *   <code>org.apache.jetspeed.om.security.UserNamePrincipal</code>
     *   <code>org.apache.jetspeed.om.security.UserIdPrincipal</code>
     *
     * The security service may optionally check the current user context
     * to determine if the requestor has permission to perform this action.
     *
     * @param principal a principal identity to be retrieved.
     * @return a <code>JetspeedUser</code> associated to the principal identity.
     * @exception UserException when the security provider has a general failure retrieving
a user.
     * @exception UnknownUserException when the security provider cannot match
     *            the principal identity to a user.
     * @exception InsufficientPrivilegeException when the requestor is denied due to insufficient
privilege
     */
    JetspeedUser getUser(Principal principal)
        throws JetspeedSecurityException;


The problem is with the second paragraph. I'd like to see these
interfaces modified to pass context explicitly, that is:

    JetspeedUser getUser(Principal principal, JetspeedUser userContext)
       throws ...etc;


The motivation for this is to permit providers to be written as plugins
that may be called from other plugins (ie, using a simple multiplexing
security provider supported by a MultiplexingJetspeedUser class), which
I hope is a more concrete motivation for this modification than the -
primarily aesthetic - arguments I provided earlier.


We're currently working around this by using a bridge to a very similar
set of security provider plugins; however, this currently prevents
"black-box" reuse of the existing turbine provider, which is a shame.

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
Semantic rules, OK?


--
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