CALL FOR: org.mmbase.security.AuthenticationData
Called by: Michiel Meeuwissen Total tally on this call : +7
START OF VOTING: 2005-02-23 16:30 END OF CALL: 2005-02-28 16:30
YEA (7) : Johannes Verelst, Gerard van Enk, Andre van Toly, Marcel Maatkamp, Rico Jansen, Kees Jongenburger, Pierre van Rooden
ABSTAIN (0) :
NAY (0) :
VETO (0) :
No votes, assumed abstained (9): Daniel Ockeloen, Jaco de Groot, Rob Vermeulen, Nico Klasens, Rob van Maris, Mark Huijser, Ernst Bunders, Eduard Witteveen
Vote result: call succeeded, hack can be added
Michiel Meeuwissen wrote:
CALL FOR: Introducing an interface org.mmbase.security.AuthenticationData,
implemented by org.mmbase.security.Authenticate and returned by
org.mmbase.bridge.CloudContext#getAuthentication.
See also this thread:
Feb-07 19:39 To [EMAIL PROTECTED] ( 142) [Developers] Request for comments: changes in security
org.mmbase.bridge.CloudContext currently contains the following method:
public Cloud getCloud(String name, String authenticationType, Map loginInfo) throws NotFoundException;
There are a few issues, which are addressed by this hack.
AuthenticationType? ------------------- The hack is in the first place about the second argument 'authenticationType' (which corresponds to the 'authenticate' attribute of mm:cloud)
Different security implementations can accept different values for this String. Most commonly accepted are 'anonymous', 'name/password' and 'class'.
There is no way to know what strings are supported by the current security implementation, nor what would be a 'logical' value in the current installation.
Of course, when you make custom code (e.g. a JSP) you know what security you installed, so you can also know which values can be used here. But this is not an option when making generic pages like the JSP's in /mmbase/edit and /mmbase/admin.
Method? -------
Related to this is the concept of 'authentication method' which is currently present in the mm:cloud tag. This takes values like 'delegate', 'logout', 'anonymous', 'http' and 'loginpage'. This specifies if and how the authentication must happen.
When a page needs authentication it defaults to http basic authentication
'http'. But this of course presumes that name/password authentication is
an option. So, I propose the move the whole concept of 'authetnication
method' to the authentication implementation as well. Then security
implementations have influence on this, and can communicate to the users
that there is no point in http authentication because it simply does not
support that.
The method String getDefaultMethod accepts another String as argument which represents the 'protocol', as e.g. returned by ServletRequest#getProtocol. This would normally be "HTTP/1.1" or so, or rather unimportant, but this anticipates authentications working through other protocols. We could e.g. imagine the "RMI" protocol. I implemented it twice (in Authentication, and in ASelectAuthentication) and both times I only distinguished http from everything else.
LoginInfo? ----------
The remaining problem is what to fill in for the needed Map (the third argument of getCloud). How to fill this Map is dependend on the authenticationType and security implementation as well.
We have a nice way to communicate this kind of information, and it is available in the bridge already. It is called 'Parameters'. Parameters is not a Map, as needed in this case, but convientently has a method 'toMap'.
So, I think a method on Authentication 'getParameters(String authenticationType)' seems logical.
In other words, actually I did grant Eduard's suggestion after all. This is better though (then public String[] getLoginInfoKeys(String application)), because besided the keys, it also communicate the types of the values, and will automaticly be checked for correctness.
Proposal --------
A new interface org.mmbase.security.AuthenticationData, with methods
getTypes, getDefaultMethod, getParameters. Attached.
org.mmbase.security.Authentication implements this interface with reasonable defaults, which mimics the current implementaiton in security implemntations and CloudTag. Authentication as a few more methods like 'login' and 'load' for which I see no place in bridge, so I did not include them in the interface.
Security implementation can make smart use of this (e.g. the ASelect implementation which I will propose as a hack as soon as it is clear how that needs to be done will do so).
A new method on CloudContext:
/** * Acquires information about the currently configured Authentication implementation. * @since MMBase-1.8 */ public AuthenticationData getAuthentication();
which simply returns mmb.getMMBaseCop().getAuthentication();
The 'AuthenticationData' interface will be added to RMMCI.
CloudTag will be changed to make use of the methods in AuthenticationData.
This change is (of course) only for CVS HEAD (MMBase 1.8).
Method and interface names are open for discussion if someone comes with something which is clearly better.
-- Pierre van Rooden Mediapark, C 107 tel. +31 (0)35 6772815 "Anything worth doing is worth overdoing." _______________________________________________ Developers mailing list [email protected] http://lists.mmbase.org/mailman/listinfo/developers
