Hi, I think the described changes are a great improvement. The separation between User and UserContext has presented me with similar problems, but one is missing, I think.
In some pieces of code I call Authorization.check(UserContext, int, Operation) myself. This method needs a UserContext object, which I build from Cloud.getUser().getIdentifier() since it cannot be retrieved any other way. Can the signature of Cloud.getUser() be changed to return a UserContext (or can a method Cloud.getUserContext() be added)? And then a question out of curiosity: what does the method getDefaultApplication(int) do? I do not see an equivalent method in the current CloudTag. Or is it mapped to the authenticate attribute on CloudTag? About the anonymous cloud issue I talked about earlier, I certainly think it is related. If I explicitly state in every mm:cloud tag I would like to use a particular authentication implementation (<mm:cloud method="sessiondelegate" authenticate="entree">), I do not like to see an attempt to use an anonymous cloud. If the security implementation is able to define what the preferred authentication method will be, I also would like to see only that one used. I hope these changes pass the vote, Ronald. > -----Oorspronkelijk bericht----- > Van: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Namens Michiel Meeuwissen > Verzonden: maandag 7 februari 2005 19:40 > Aan: [email protected] > Onderwerp: [Developers] Request for comments: changes in security > > > I just expirimented with some changes in the security layer > and bridge, and I'd like feed back about it. > > There are two things which I targeted to change. > > 1. Merging of org.mmbase.bridge.User and > org.mmbase.security.UserContext. > > This is a long standing irritation. The sad thing is that > you cannot do > something about it absolutely backwards compatibly. > > The bridge 'User' object has a few methods which miss in security > UserContext: > boolean isValid(), > String getAuthenticationType() > > , it's not hard to simply put them in UserContext. > > The most irritating though, is the difference: > bridge.User: String getRank(); > security.UserContext: Rank getRank(); > > Since a 'String' representing a Rank is totally useless I > find myself > constantly translating it to the Rank object with the > static method 'getRank' > of security.Rank. > > I tried throwing away bridge.User and > bridge.implementation.BasicUser and > simply use security.UserContext on the few spots in the > bridge where it > is used.. It is a security related object, so I don't > really see the > point of an extra interface in the bridge for it. > > Everything which doesn't compile then can easily be > repared, and usually > becomes a lot nicer. > > E.g. in BasicNode there are 8 of these kind of changes: > < node.insert(((BasicUser)cloud.getUser()).getUserContext()); > --- > > node.insert(cloud.getUser()); > > Nicer, isn't it? > > A handfull of changes of this type in BasicCloud: > < Authorization.QueryCheck check = > auth.check(userContext.getUserContext(), query, Operation.READ); > --- > > Authorization.QueryCheck check = auth.check(userContext, > query, Operation.READ); > > IHO also clearly an improvement. > > > Taglib (especially cloudtag) suffers a bit too. > > For example in this way: > < Rank curRank = Rank.getRank(cloud.getUser().getRank()); > --- > > Rank curRank = cloud.getUser().getRank(); > > Much better, i think.. > > Security implementations may also break, but also only when there is > hackery, for example in CloudContext security there is some > stuff which > uses a bridge node (provided by a 'function'). This can > simply become > UserContext then. All other known security implemntations > still compiled. > > > RMMCI broke too, but I suppose it can be fixed (Keesj?) > > Probabaly the inverse could be done too: Dropping > security.UserContext in > favour of bridge.User, or make it implement Use. I think it > would cause > about the same amount of trouble, though perhaps on other > places. The > bridge interface must change then, because I really hate > String getRank(), > and it gets used on odd places like in MMObjectNode, and > the security > implementation themselves. > > I will perhaps propose something more concrete for this > change soon, but > I'd like your ideas first. If people object any > backwards-incompatible > chagne, and rather live with the current cumbersomeness I > could as well stop > now. > > > > 2. Additions of > bridge.CloudContext: > public int getMethod(String m); > public int getDefaultMethod(); > public String getDefaultApplication(int method); > > which wrap the same methods on security.Authentication. > > The implemention of getMethod and related constants I > wanted to move from > CloudTag (which cleans it up a bit as well...) > > CloudTag then uses getDefaultMethod and getDefaultApplication when > 'method' and/or 'application' attributes are not set, or > set to 'default' > or so. > > This makes it possible to make the behavior of Cloud tag > being influenced > by the actual security implementation. > > E.g. cloud-tag now defaults to 'http' / 'name/password' > which makes sense for > a lot of security implemetnation but not for every one. > (not e.g. for the > 'ASelect' implementation I talked about last week). > > Of course jsp's can still explicitely specify the 'method' for > authentication , but that is only possible if you know the security > implementation. So, for our site using 'Aselect' security, > we needed to > hack the generic editors and admin pages. A change with the > above methods > would render that unnecessary. In other words, you could > more easily make > templates which are independent of the security implementation. > > I should perhaps also look into the 'anonymous' cloud issue > of Ronald, > which seems related to this, but I have not yet a clear > idea of that, or > worked it out in any grade. > > I think others must have run into these problems before, > and may have > thought about (or even hacked) a possible solution, which > they may want to > share at this point. > > If no reactions follow, I will make this more concrete and > tested, and > propose a hack proposal about this soon. > > > So, i think there are 2 or 3 issues with security, which can > all relatively easy fixed by 2 or 3 hack-proposals. The other > option would be to create a small 'security 2' project for > this or so, if one would prefer that (personally I don't > think that is needed). > > > Michiel > > > > -- > Michiel Meeuwissen mihxil' > Mediacentrum 140 H'sum [] () > +31 (0)35 6772979 nl_NL eo_XX en_US > > > > _______________________________________________ > Developers mailing list > [email protected] > http://lists.mmbase.org/mailman/listinfo/developers > > -----------------------Disclaimer------------------------- Dit bericht (met bijlagen) is met grote zorgvuldigheid samengesteld. Voor mogelijke onjuistheid en/of onvolledigheid van de hierin verstrekte informatie kan Kennisnet geen aansprakelijkheid aanvaarden, evenmin kunnen aan de inhoud van dit bericht (met bijlagen) rechten worden ontleend. De inhoud van dit bericht (met bijlagen) kan vertrouwelijke informatie bevatten en is uitsluitend bestemd voor de geadresseerde van dit bericht. Indien u niet de beoogde ontvanger van dit bericht bent, verzoekt Kennisnet u dit bericht te verwijderen, eventuele bijlagen niet te openen en wijst Kennisnet u op de onrechtmatigheid van het gebruiken, kopi�ren of verspreiden van de inhoud van dit bericht (met bijlagen). This message (with attachments) is given in good faith. Kennisnet cannot assume any responsibility for the accuracy or reliability of the information contained in this message (with attachments), nor shall the information be construed as constituting any obligation on the part of Kennisnet. The information contained in this message (with attachments) may be confidential or privileged and is only intended for the use of the named addressee. If you are not the intended recipient, you are requested by Kennisnet to delete this message (with attachments) without opening it and you are notified by Kennisnet that any disclosure, copying or distribution of the information contained in this message (with attachments) is strictly prohibited and unlawful. ---------------------------------------------------------- _______________________________________________ Developers mailing list [email protected] http://lists.mmbase.org/mailman/listinfo/developers
