About setting up Container security for JSPWiki I had a couple years ago written about in
https://jspwiki-wiki.apache.org/Wiki.jsp?page= JSPWikiContainerManagedAuthenticationInstallation And yes, the default policy file should be more restricted. Juergen Am 06.10.2017 12:21 schrieb "Paul Uszak" <[email protected]>: > Yes a definitive tutorial would be a beginning. But herein lies a > problem. Juergen, what are you talking about with your 2nd paragraph? Non > of this is in the "Quick and simple install" section @ > https://jspwiki-wiki.apache.org/Wiki.jsp?page=Getting%20Started. Do you > see > what I mean? I tried a fresh install yesterday and fell flat on my face at > step 3. It just doesn't work whereas my SimpleSite experience was > wonderful. Grr emoji. > > With almost infinite undefined security configurations as you've just > illustrated, JSPWiki is equally vulnerable. It ships with anonymous users. > As soon as you turn it on, all the pages and comments get spammed so hard > that I get Java out of memory errors. I've also documented an inability to > log out. We cannot rely on container managed security because it doesn't > work easily with the wiki. If it used one or the other we'd be fine, but it > uses all of them all of the time. Adding more JAAS functionality really > isn't the way forward. That's another (enterprise) layer added on top . > It's clearly unsustainable and this is borne out by the adoption > statistics. I'm thinking of dropping it as well as it takes way too much > effort, even to simply reinstall. But as I opportunistically pointed out > earlier, there's scant alternative for a simplistic text based site. > > If I had the requisite skills, my approach would be to fork it, strip it > and call it "Kitten". A re architecture to a MVC pattern like Struts2 > would be ideal as JSP is really a presentation technology isn't it? That > would be a clear migration path and a lot of the code could be reused. > Pity I'm too thik... > > On 6 October 2017 at 07:28, Jürgen Weber <[email protected]> wrote: > > > Wouldn't a good tutorial be enough? > > > > Basically you just have to add a user to tomcat-users.xml, enable > container > > managed security in web.xml and edit the policy (maybe we should include > > the default policy, that is more restricted and just works). > > > > Wordpress and friends have zillions of security holes, whereas we can > rely > > mostly on proven container security. > > > > Juergen > > > > Am 06.10.2017 01:35 schrieb "David Vittor" <[email protected]>: > > > > > I kind of feel both sides of the argument are right here. Even though > > > JSPWiki has a pretty great authentication system, the problem is it's > not > > > very user friendly. > > > > > > The solution I think is to build some sort of an "admin" UI into JSP > wiki > > > which lets users configure group/user permissions, and then saves these > > > into the back end jspwiki.policy file. > > > > > > I think that is one thing that Confluence did really well, even though > > the > > > backend is complex the front end is easy to manage. I think JSPWiki > needs > > > to the same. There is actually in the code a "hidden" admin page, but > > it's > > > very buggy, and not sure how much additional work is needed to make > this > > > public. > > > > > > The other solution might be to use the tomcat group/user configurations > > > with JAAS, but this probably needs better documentation, that is easy > to > > > follow. > > > > > > Every person/organisation has different requirements for how they want > > > security to work. But that should not stop us making every effort to > make > > > it more user friendly. > > > > > > Anyway they are my thoughts. > > > > > > Cheers, > > > David V > > > > > > > > > > > > > > > On Fri, Oct 6, 2017 at 10:01 AM, Paul Uszak <[email protected]> > > wrote: > > > > > > > "What is JSPWiki for?" This then is the question. If we kneel before > > our > > > > god(s), hands on heart, lovingly think of our grandmothers and ask > > > > ourselves “Can JSPWiki effectively compete in the content management > > > > market” , what's the honest answer? I think deep down in our souls > > it's > > > an > > > > emphatic “no”. > > > > > > > > I created a test Wordpress account last night in under five minutes. > It > > > > looks great and you get free hosting. Wix offers even more > fantastical > > > > creativity when you enrol. And xml editing wasn't needed. Foswiki > is > > > more > > > > powerful and polished, and used extensively. Pretty tough > competition. > > > > > > > > But the market isn’t crowded at the bottom. It’s empty. This isn’t > a > > > daft > > > > strategy. It’s the quintessential definition of strategic marketing. > > An > > > > analogous example is the tool Vi. Vi is still cherished and > > extensively > > > > used, even today configuring state of the art IaaS deployments. > Simple > > > can > > > > be successful. I can see a need (which is where I came on board) > for a > > > > plain and simple Wiki. I use mine as a single user web site where it > > > acts > > > > as a content management system. > > > > > > > > Low system requirements, low bandwidth and most importantly, low > > > > configuration. Zero configuration to start. The details can be > > thrashed > > > > out later, but JSPWiki’s offering and place in the market must be > > > resolved > > > > for success. I’ve posed this question before, but I’m not sure that > > > > there’s sufficient appetite for answering it sincerely. C'est la > vie. > > > > > > > > > > > > On 5 October 2017 at 21:49, Jürgen Weber <[email protected]> wrote: > > > > > > > > > Jim, > > > > > > > > > > I also think the JSPWiki Authorization system is very good. The > > > > > container looks after authentication, and the policies decide what > > the > > > > > Container authenticated user is allowed too. > > > > > > > > > > Kudos to Andrew Jaquith (https://www.ecyrd.com/ > > > > JSPWiki/wiki/AndrewJaquith) > > > > > > > > > > Juergen > > > > > > > > > > https://jspwiki-wiki.apache.org/Wiki.jsp?page= > > > > > JSPWikiContainerManagedAuthenticationInstallation > > > > > > > > > > 2017-10-05 10:39 GMT+02:00 Jim Willeke <[email protected]>: > > > > > > Try not to think of it as infinite complexities but rather > infinite > > > > > > Combinations. ;) > > > > > > > > > > > > And if you have a suggestion or a request for an improvement, I > am > > > sure > > > > > > folks would listen. > > > > > > > > > > > > I do agree many of the JSPWiki pages could use some refactoring. > > > > > > As with MOST open source projects the docs and code they are out > of > > > the > > > > > > beyond the realm of understanding for "common folk". > > > > > > > > > > > > Oh, and on "And how can you even dream of having anonymous users > on > > > an > > > > > > internet facing > > > > > > wiki?" > > > > > > Many are, even Wikipedia. > > > > > > > > > > > > And as far as "What is JSPWiki for?", I agree it is somewhat of a > > > > > > middle-road undefined product. > > > > > > > > > > > > - Not for the Enterprise as there is AFIK, no method to keep > the > > > > sales > > > > > > dept separate from the engineering dept. (Well no reasonable > > tools > > > > to > > > > > make > > > > > > it happen) > > > > > > - Not for the Casual user as there is too much Flexibility. > (or > > > > maybe > > > > > > too much Complexity). Perhaps most Casual users would be > better > > > off > > > > > with > > > > > > a "hosted" solution. (https://www.blogger.com/ or something) > > > > > > - Is not designed (or packaged) to be "dropped in" a SaaS like > > > > Google > > > > > > App Engine (or whatever AWS and Microsoft Hosting has to offer > > in > > > > that > > > > > > line.) > > > > > > - Perhaps it is best as a toolkit to be embedded within > another > > > > > product > > > > > > offering? > > > > > > > > > > > > So I agree it is somewhat a "For anyone" which is NEVER the right > > > > answer > > > > > > for todays crowded market if you want to Succeed. > > > > > > > > > > > > If you would like some help, please provide some details on your > > > > > > configuration. > > > > > > Are you on Tomcat? > > > > > > Do you have Container Authentication turned on? > > > > > > > > > > > > Have you altered the WEB-INF/jspwiki.policy file? > > > > > > > > > > > > Any other details you think might be helpful. > > > > > > > > > > > > > > > > > > -- > > > > > > -jim > > > > > > Jim Willeke > > > > > > > > > > > > On Wed, Oct 4, 2017 at 6:45 PM, Paul Uszak <[email protected] > > > > > > wrote: > > > > > > > > > > > >> I'm sorry Jim, I can't even remotely begin to agree with you. > > > > > >> > > > > > >> There are not *some* complexities. There are almost infinite > > > > > >> complexities. Some of this might be clear to a professional IT > > guru > > > > like > > > > > >> yourself, but (I will wager) that most cannot scratch even the > > > > surface. > > > > > >> The document you link to is 7000 words long, and includes > > enterprise > > > > > JAAS > > > > > >> configuration that is on (it states) by default. What? And > > implied > > > > > >> permissions? It reads like a matrix of potential security > > > > combinations. > > > > > >> > > > > > >> We don't even know what the relationship is between container > > users > > > > and > > > > > >> wiki users. Are they the same? And what then about the wiki > > groups & > > > > > >> container roles? Are they the same? I'm in the odd state of > not > > > > being > > > > > >> able to log out of the wiki. If I log out and the page says > > logged > > > > out > > > > > >> G’day (what is that, Klingon?) I just hit back on the browser > and > > > I'm > > > > > back > > > > > >> in and able to edit! That's a trivial example, but illustrates > > the > > > > > point > > > > > >> well. > > > > > >> > > > > > >> And how can you even dream of having anonymous users on an > > internet > > > > > facing > > > > > >> wiki? As soon as you try to implement some form of primitive > > > security > > > > > >> against the evil hordes out there, you run afoul of the > > > *flexibility*. > > > > > I > > > > > >> think that you have to conclude that the whole security thing's > a > > > > mess. > > > > > >> You might want to review the holistic scope of barriers to > > adoption. > > > > > The > > > > > >> reasons run deep and I've written on them previously, but I > guess > > > that > > > > > >> nothing is likely to improve. *What is JSPWiki for?* I'd > dearly > > > love > > > > > >> JSPWiki to succeed, but honestly I cannot see a way forward even > > > > though > > > > > I > > > > > >> keep desperately searching. Naff powers of persuasion I guess. > > > > > >> > > > > > >> Unfortunately at this moment I'm repurposing my wiki so there's > a > > > > fierce > > > > > >> debate between heart and mind as to whether I should seek > greener > > > > grass. > > > > > >> Is this too -ve? > > > > > >> > > > > > >> On 4 October 2017 at 14:01, Jim Willeke <[email protected]> > wrote: > > > > > >> > > > > > >> > While I somewhat agree that an implementation of using an > > > > externalized > > > > > >> > Access Control Model would be better in some respects, I do > find > > > > that > > > > > the > > > > > >> > current implementation is well thought out and quite flexible > > for > > > > Wiki > > > > > >> > usage. > > > > > >> > > > > > > >> > Any Java Container implementation must simultaneously deal > with > > > file > > > > > >> > permissions, web container permissions, java.policy. > > > > > >> > > > > > > >> > WIKI-Groups and Page ACLs were deliberately meant to be > managed > > > > > outside > > > > > >> of > > > > > >> > the web container or java.policy so that users can create > > > > > discretionary > > > > > >> > "roles" without getting system admins involved. This is an > > > > intentional > > > > > >> > feature, and a very powerful one which along with Page ACLs > > > reduces > > > > > the > > > > > >> > barrier to adoption. > > > > > >> > We all know the difficulty of getting some administrator in > some > > > > other > > > > > >> area > > > > > >> > of an organization to grant (or deny) access to a "thing". > > > > > >> > > > > > > >> > Note that the hierarchy for Access Control is: (I do not see > > this > > > > > >> > documented, it was in a user group a few years back) > > > > > >> > > > > > > >> > - "built-in" roles > > > > > >> > - container-managed roles > > > > > >> > - WIKI-Groups > > > > > >> > - WIKI-Profiles > > > > > >> > > > > > > >> > AFIK, any "Container" implementation deals with deal with file > > > > > >> permissions, > > > > > >> > "Container" permissions. > > > > > >> > > > > > > >> > There are some complexities that may documented but not so > well > > > for > > > > > those > > > > > >> > not familiar with the concepts. > > > > > >> > I think this page probably summarise most of the concepts: > > > > > >> > https://jspwiki-wiki.apache.org/Wiki.jsp?page=Wiki.Admin. > > Security > > > > > >> > > > > > > >> > Questions, Comments and Suggestions for improvements are > always > > > > > welcome. > > > > > >> > > > > > > >> > -- > > > > > >> > -jim > > > > > >> > Jim Willeke > > > > > >> > > > > > > >> > On Tue, Oct 3, 2017 at 10:06 PM, Paul Uszak < > > [email protected] > > > > > > > > > >> wrote: > > > > > >> > > > > > > >> > > Well I still have trouble with the permissions /users after > a > > > > > couple > > > > > >> of > > > > > >> > > years. All sorts of weird things happen. > > > > > >> > > > > > > > >> > > I've stated previously that I consider the security > > > configuration > > > > > >> > > extremely complicated, bordering on unusable. You cannot > > have a > > > > > >> credible > > > > > >> > > product that uses (simultaneously) file permissions, web > > > container > > > > > >> > > permissions, wiki policies and per page directives. I can't > > > think > > > > > of > > > > > >> > > another application that has such complex security across so > > > many > > > > > >> levels. > > > > > >> > > It's madness - do you hear me? Sheer madness :-) > > > > > >> > > > > > > > >> > > Seriously, I would suggest a total overhaul to simplify > > > > massively. > > > > > I'd > > > > > >> > > even consider writing some clearer documentation. It might > > > > reduce > > > > > the > > > > > >> > > number of set up issues that appear here. Although, with > four > > > > > >> dimensional > > > > > >> > > security I suspect I'm not up to it. > > > > > >> > > > > > > > >> > > What was the question again..? > > > > > >> > > > > > > > >> > > It seems to me that if only the front page is publicly > > visible, > > > it > > > > > >> > needn't > > > > > >> > > be within the wiki's context. Simply have a static front > page > > > at > > > > > one > > > > > >> > URI, > > > > > >> > > and have the private wiki at another. It also means you > don't > > > > have > > > > > to > > > > > >> > > explain why you're being unfriendly as the wiki will be > > > invisible > > > > > >> > > (unlinked). I have something similar myself. Or have I > > > > > misunderstood? > > > > > >> > > > > > > > >> > > On 3 October 2017 at 20:09, Jürgen Weber <[email protected]> > > > wrote: > > > > > >> > > > > > > > >> > > > Hi, > > > > > >> > > > > > > > > >> > > > I followed Dave's blog entry at > > > > > >> > > > > > > > > >> > > > https://blog.davekoelmeyer.co. > nz/2014/07/20/configuring-a- > > > > > >> > > > public-jspwiki-instance-for-private-use/ > > > > > >> > > > > > > > > >> > > > Has someone tried to keep the front page public? (i.e. to > > > give a > > > > > >> > > > friendly reason for the rest of the pages being private) > > > > > >> > > > > > > > > >> > > > I tried to give all front facing pages [{ALLOW view ALL}] > > > > > >> > > > but still only the login prompt. > > > > > >> > > > > > > > > >> > > > Greetings, > > > > > >> > > > Juergen > > > > > >> > > > > > > > > >> > > > > > > > >> > > > > > > >> > > > > > > > > > > > > > > >
