portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Sean Taylor" <da...@bluesunrise.com>
Subject RE: Security 1.4: more implement[eo]r feedback on provider APIs
Date Mon, 05 Aug 2002 19:12:56 GMT
I believe at first you only wanted to change the logout method. Am I correct
to say that now you want to change all the security calls to explicity pass
in the current user?


> -----Original Message-----
> From: Jan Grant [mailto:Jan.Grant@bristol.ac.uk]
> Sent: Monday, August 05, 2002 6:49 AM
> To: Jetspeed Developers List
> Subject: Security 1.4: more implement[eo]r feedback on provider APIs
>
>
> 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>



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