Protecting a TiddlyWiki behind SSO authentication?

[springer]

Folks,

Increasingly, I'm wishing to make work-related TiddlyWiki files available to people who pass through the institution's authentication process. 

I'm not yet even talking about multi-author here (although I had a great experience with getting set up by Jeremy to try that with a batch of students during the spring crisis semester). 

Rather, I need view-only access (at least) to be available to exactly those who have passed through the university's security gates.

I know next-to-nothing about how an html file on a server interacts with an SSO system (there are cookies, tokens, Active Directories and ...?). (I'm not clear on whether an html file itself needs certain features, or whether a server can be configured to limit access to this or that directory of ordinary html files, showing them to all and only those who clear the SSO.)

It seems to me that much is at stake for TiddlyWiki in being able to get hosted in this way. When I use my university's Microsoft Teams system, for example, I can specify a "Team" of people (each authenticated via the SSO), and then link that team to dozens of "apps" (diagrammers, databases, mind-maps, collaboration tools, project managament, kanbans, wikis [cringeworthy ones, as far as I can tell]...). Once I add content within that team's virtual content area, there's a little gated community of access to that content.

I showed one of my tiddlyspot sites to my helpful IT person and asked whether the university cost host a tiddlywiki file on a server on its domain somewhere such that access would be limited to members of such a team (or in any other way mediated by our SSO's AD subsets). The response was a whole bunch of enthusiastic suggestions about available apps that I could work with *instead* -- apps that would (from her point of view) serve the same functions as TiddlyWiki. 

It was a sad moment. I did persuade this one person that TW is not a platform I'm about to swap out (partly by offering a tour through that tiddlyspot site, showing its versatility). But the point is that competent IT folks at institutions are oriented to the kinds of tools that function as modules within ecosystems like Teams. 

To be clear: the pivotal issue isn't playing with Microsoft Teams per se; it's how a tiddlywiki can be shielded by the SSO process. For certain kinds of information, a university (or other large collective) doesn't want its data living out there on an unrelated server, protected (if at all) only by a password that has nothing to do with their authentication process.

Any thoughts? (If it's already possible with out-of-the-box TiddlyWiki, so long as we set up a certain server niche, I can bring the issue up with other IT specialists here, but I don't even know yet what language I'd need to be speaking to ask the right questions.)

-Springer

[Eric Shulman]

On Saturday, June 20, 2020 at 12:16:07 PM UTC-7, springer wrote:

I showed one of my tiddlyspot sites to my helpful IT person and asked whether the university cost host a tiddlywiki file on a server on its domain somewhere such that access would be limited to members of such a team (or in any other way mediated by our SSO's AD subsets). The response was a whole bunch of enthusiastic suggestions about available apps that I could work with *instead* -- apps that would (from her point of view) serve the same functions as TiddlyWiki. 

As you know, a TiddlyWiki is *just* an HTML file... not an "app" in any conventional sense.

Instead of showing them one of your TiddlyWiki files (and how wonderful and versatile it is!), I'd simply say:

"I have a single HTML file (and perhaps related image files) that I'd like to post to an SSO-protected website.

How can I upload those files so that only users of that SSO can *view* them in their web browser?"

This hopefully avoids any apprehension they may have that TiddlyWiki could pose any security risks.

-e

[springer]

Eric, that is roughly what my first very first query indicated (that I wanted to host an html file in that way)... Once it was clear that this wasn't a "dumb" web page (for which they want to sell me on enhanced substitutes), they replied with something about only hosting content that they were "subscribed" to... 

The fact that TiddlyWiki is open-source and very well established didn't seem to bypass that concern... 

I suppose it's something about needing to feel like they can "support" whatever kinds of information-resources exist on their own servers. (As if I'd go knocking on their door when I run into some challenge with developing my TW content...) 

Anyway, I will keep following up in hopes that they can give me a server space that works within the relevant permissions.

I do think that if TiddlyWiki gets a real footprint in educational settings (which might in turn benefit from something like an off-the-shelf "package" with plugins that reduce the learning curve for educators), its profile will take off. 

Thanks!

-Springer

[Saq Imtiaz]

Is there an actual policy that prohibits use of TW, considering that there is no server component and it would be read only?

If not, one approach is to show them some static HTML exported from TW and ask about how to host that and other similar files using SSO protection.

Once you know how, hosting one HTML file is as easy as hosting another.

[TW Tones]

Springer,

This is actual quite a big subject, I would be happy to look at this with you at length. Let me however make a few points that may lead you to a solution first.

• Consider TiddlyWiki single files as a "smart document", basically they are a document like any other file, but they use a browser to provide for editing. The smart comes from it ability to customise functions and features in the document itself.
• If someone can't get to the file they can't get the content - they use an organisations standard security
• Unlike documents, unless you have a local app like tiddlydesktop the browser security is an additional level of security standard documents don't have, for example word and excel macros can wreak havoc on the local computer.
• If you can view something, anything, you can copy and export it, this is true with almost anything, this is no different with tiddlywiki, though unlike other documents you can configure tiddlywiki to make modification difficult. To expect a higher level of security than that, from tiddlywiki is unreasonable. Only line of business applications using a server and client has a chance of securing data more tightly - but it is still, if you can see it you can copy it rule, and now days many line of business apps are in the cloud with their own security issues.
• If you have a secure file on a system, that only authorised people can write to that file and location,will guarantee it is the source of truth, because people can not write back to the file unless permitted to do so, even if they make it look different in their browser.
• If you are using Microsoft teams you should be able to share tiddlywiki's like documents, and choose the rights to save. 
• I have written a business application in tiddlywiki that uses sharepoint (Teams is on top of sharepoint in many ways), the key is demanding checkout before you can save, and renaming .html to .aspx
• I have posted on this previously - To get it to load quickly I put it in a wiki library
• I was a global admin for microsoft O365 and SharePoint for some years, then I changed roles and lost my permissions, but I was able to get anything I wanted with a little "legitimate hacking". 
• With a few tricks, the best way to host tiddlywiki I have found in a corporate Office environment only requires write access to a wiki library and some "secret knowledge"

In closing I stand ready to implement tiddlywiki solutions for other businesses in the future, so shared effort on this issue has relevance to my business.

Perhaps we could build a business case document?

Alternatively as a former super admin and being aware of the machinations in IT Departments, I personally would ignore them all, and would workaround their ignorance.

Regards

Tony

[Eric Shulman]

On Saturday, June 20, 2020 at 4:46:46 PM UTC-7, TW Tones wrote:

This is actual quite a big subject, I would be happy to look at this with you at length. Let me however make a few points that may lead you to a solution first.

Your points are all valid.  However, the specific problem here is the organizational culture.  University IT departments tend to be very inflexible and overly cautious about the technology that they allow.   They are extremely defensive about their control of the IT environment (even more so than in the corporate business world).  My sister is a professor (University of Virginia, as well as several online institutions of higher learning), and she faces this issue all the time.

Perhaps it is because the IT folks are working with a combination of non-technical educators that can easily screw up their systems, as well as highly-technical educators that often know more about the technology than they do.  In either case, their jobs are hanging by a thread and it takes a VERY long time (months or even years!) to get even the most simple IT changes approved and implemented.  Trying to convince the IT department to add more security technologies won't work because the problem isn't technical... it's social.  The only hope is to find a senior IT person who is secure enough in their position, and has enough power in the organization to be willing to entertain new possibilities and procedures.

-e

[TW Tones]

Eric,

I understand, A lot of universities also train future black and white hat hackers. I have had friends the University did not know if they should expel them for breaching security or award them the highest honours for cracking security systems. The same conservatism  is also for many corporate, all too commonly security is the proverbial "tail wagging the dog". To me quality security is possible that does not limit capacity, creativity and the core business but that needs too much enlightened management and specialists than most organisations have.

In such cases it is important to put the issues in context, that is what I hoped to do with my post. 

• Single File wikis can be considered documents
• They have the added security that modern browsers enforce on them unless you use other savers and utilities
• TiddlyWiki like any document lives at the end of a file or URL, if someone does not have access they will never find it
• Like any other document and website, if you can read it you can steel it

I agree you should seek support, but sometimes it is best to prepare for a discussion but "don't stick your head above the parapet" and do "guerilla" IT if you know you are in an organisation with unenlightened IT policies or uninformed closed minds.

We each have to decide the risks we may take.

Regards

Tony