RE: [stellation-res] WVCM API Problem

["Jonathan Gossage" <jgossage@xxxxxxxx>]

> -----Original Message-----
> >>
> >>> I have been going through the WVCM API and have found a problem area
> >>> that
> >>> makes it unnecessarily difficult to use strong authentication. Since
> >> JSR147
> >>> is in the public review period until Dec. 3, 2003, I believe we
> >>> should
> >>> submit a comment to that group. The generalization that is necessary
> >>> to
> >> make
> >>> it easy to use strong authentication is trivial and I could prepare a
> >> short
> >>> document for us to review if you would like.
> >
> > I've got a more direct channel for suggesting changes to the standard.
> > I'll
> > be talking to the WVCM spec author on thursday. (Geoff is a friend of
> > mine.)
> >
> > What's the problem with strong authentication in WVCM? WVCM is designed
> > to sit over WebDAV, which allows the use of cryptographic challenge
> > authentication, which seems adequately strong. But I'm not a crypto
> > expert at all - and, I expect, neither is Geoff. So what's the issue?
> >
> >>  I forgot to mention that I am planning to write a document that will
> >> recommend that we use JAAS as our authentication and authorization
> >> framework. Given this our current authentication and authorization
> >> support
> >> can be simply encapsulated in a JAAS wrapper. This approach will
> >> allow us
> >> and others to easily provide strong authentication for Stellation.
> >
> > Gaah. I bought a book on JAAS about a year ago, and concluded it
> > was a horrible, overcomplicated, incredibly painful API, and that it
> > looked
> > like a nightmare to administrate a system that used it.
> >
> > What kind of benefit are we going to see by replacing the current
> > auth/auth system in Stellation with JAAS?  (It's going to have to be
> > a pretty big one to convince me!)
> >
> > 	-Mark
The primary goal is to provide a pluggable authentication and authorization
capability. JAAS is a publicly defined mechanism to achieve this.

It would also be possible to provide extendability via an Eclipse extension
point but the interface would be proprietary rather than public and existing
security modules could not be used without rewritng.

The problem n the WVCM spec is in the class ProviderFactory. If you look at
the methods

String Callback.Authentication.loginName()
String Callback.Authentication.password()

and

Callback.Authentication Callback.getAuthentication(String realm, Integer
retryCount)

the return types and arguments are specified as String. It would be better
if they were expressed as Object since in many authentication environments,
the objects involved are more complex than strings. Something like:

Object Callback.Authentication.loginId()
String Callback.Authentication.credentials()
Callback.Authentication Callback.getAuthentication(Object realm, Integer
retryCount)

is more general and can be readily used by any authentication package,
including JAAS.

Regards

Jonathan