MIS Systems Thread, SIMS single sign on in Technical; Excellent job , happy to help test if time permits.
I had a routine i wrote to intercept logins and ...
13th February 2014, 12:13 PM #16
Excellent job , happy to help test if time permits.
I had a routine i wrote to intercept logins and first check if an upgrade was due, so the user could opt out if they were on wireless.
Actually, just thinking it through, in order to keep that workflow for SIMS upgrades - assuming it's still a SOLUS 2 scenario. You should pass the authenticated user on to SIMSload.exe with pulsar as teh parameter.
You might consider a ver2 where you let the user specify if they want to use simsload or pulsar depending on if they are on SOLUS 2 or 3. I don't use 3, but i think it negates teh need for a simsload check. Might need to research the diff setup.
13th February 2014, 12:27 PM #17
It can do that already, as it has a variable in the config file that defines the SIMS path (so that it can be changed for 32 bit clients). If you point that to SIMSLoad instead of Pulsar, it should still work. In fact, due to its nature you could technically use it to launch any exe while first checking against AD!
13th February 2014, 12:27 PM #18
It uses the Windows token. Idea is the application will never prompt for your Windows password which could result in a man-in-the-middle attack and end up with your username and passwords being posted on pastebin along with tesco customers details.
Originally Posted by 3s-gtech
13th February 2014, 12:35 PM #19
Makes sense. Seeing as it's a simple change in SIMS itself it's no hardship, even for 110 or so users.
13th February 2014, 12:52 PM #20
This is quickly becoming marketable. :O) Stop all production and quit your job, before you lose all IP rights. We can set up a new company called "My SaSO, Your Way", and blitz the market.
Originally Posted by 3s-gtech
13th February 2014, 12:56 PM #21
That means I would have to quit too! MY CODE *gollum*
Originally Posted by vikpaw
13th February 2014, 01:05 PM #22
It's not a question of the complexity of the problem. Let me just break it down.
OK, so lets start at an odd starting point, the solution. If we, the community, create a tool that we release, we are going to reduce the security. We are, lets face it creating a man-in-the-middle attack, we do however have good intentions. Regardless, this is a security hole we are, on purpose introducing.
Now lets look at why we're doing it. I won't say why Windows logons are better than SQL logins, they just are, don't get me wrong SQL logins have a time and a place. They are brilliant for things like background tasks like B2B. We're doing it because we believe staff should re-authenticate to access SIMS. Question is why? Why should staff have to re-enter something they've already entered - after all teachers don't have to (legally) do data entry twice, why are we adding time and complexity to the situation. Are the staff logged on as a pupil? Surely not. Are they leaving their pc logged in or letting pupils using? Surely not. If the computer has SIMS installed then you can be fairly sure they have a export of sensitive information somewhere in the user documents. All it takes is a pupil or anyone for that matter to get hold of this document for your plan to fall apart. SIMS isn't the only thing you need to secure. Teachers generally have access to pupil work - if nothing more.
So, why are we doing this and not promoting locking your workstation? Seriously, login to SIMS in the morning, lock your machine when your not in front of it. Shut it down at the end of the day, how is closing SIMS every 5 mins better? Surely leaving it open is faster, even if just a few seconds then re-opening it all the time. If a pupil or someone else needs to use the machine, you switch users and SIMS will resume when they switch back. I've only ever heard 1 reason why I would even consider doing this.
Going back to the whole reason why I wouldn't do it, if you have a prompt, how will you deal with login failures - ie what's to stop a student keep try until AD locks the account out, pretty sure that's going to cause more chaos as everything stops working!
Any just my 2p, I know worse things that people believe is secure then a prompt window.
13th February 2014, 01:22 PM #23
As much as I love a good start up... There are quite a lot of reasons this might not be a great idea... least of all it won't take much for Capita to add a few lines of code and completely kick the venture into touch...
13th February 2014, 01:42 PM #24
SIMS has the trustedauto system, the benefit is that it stops them using a weak SIMS password, and it's one less set of credentials to remember, so you can enforce better password policies through Windows, and yes locking would help secure the whole system.
The slight weakness is that it does remove that barrier to entry which was there before. We have a full environment where people have to login to SIMS. What they do after and the poor practise is a separate issue. Easily mitigated by locking, true, but people don't and setting a policy, getting it agreed etc. is a pain. Not to say we shouldn't try.
All this does is ask them to login with the same credentials and so for situations as above, where they are rubbish at security, you have put in a barrier of sorts. It doesn't fix everything, but is a solution they can't argue with as it's no different to logging in like they did before except you've made the credentials the same. That is the benefit of SaSO. It's no different to implementing it on any other system, be it intranet, linked portal, any other internal or external system, that can link to AD.
It would be great if Capita did it, but when will that Change Request earn enough votes? This just does it for the schools that want it. You would have to declare in big bold letters that the by pass to the barrier is dead simple and so it's not a security implementation, but it is still useful. Granted, about as useful as taking registers during a fire! Sometimes people just want piece of mind.
If a student sees two scenarios one with auto sign in and one with a login prompt, they hopefully think the login method is a barrier and so be less likely to try and sneakily open it up if the teacher nips out or has to deal with something urgent (which could well bypass a lock your PC scenario anyway). Obviously, all the student hackers are on EG anyway, but that's besides teh point.
A student could do a lock out scenario on any PC, like they do to other students, without having to have the ldap tool.
As for Capita changing the code, all the system is relying on is the trustedauto mechanism they put in place works. Why would they stop that? Or want to prevent you from authenticating first.
I think it's a good idea, for this scenario. I'm not seriously suggesting it is marketed, come on, the bypass is as simple as typing Windows, then SIMS!
13th February 2014, 02:04 PM #25
Why would Capita spend time and money making the system LESS secure in order to add a false layer of security? The security token is MORE secure than passing your AD username and password to get a security token. It goes against everything Microsoft says.
Locking your workstation IS the way forward to secure your data. It is everyone who accesses the data responsibility to ensure they lock their workstation. It's not difficult, it's not long winded. It's simple. If they can't do that, they shouldn't have access to the data. Period.
Stop looking for workarounds, there aren't any. If it isn't policy, push it to become policy. If you're saying staff can't lock workstations then that is and will always be your weakest point regardless what software you implement or buy. It isn't IT problem, it's SLT's.
13th February 2014, 02:20 PM #26
This project isnt about staff locking their workstations, its providing Single Sign on, not having staff to remember yet another password, enabling them to be more efficient and productive, might mean they start the lesson 5 minutes sooner, all those 5 minutes adds up
Yes, staff should lock their workstation and our's here do, they are proactive about security. I think you have slightly strayed off topic here, as the entire topic was about creating Single Sign In, not the politics surrounding security of workstations.
(We currently have single sign on for all our web services, email etc - SIMS is the only one not linked, and now it is!)
Last edited by SovietRussia; 13th February 2014 at 02:21 PM.
13th February 2014, 02:24 PM #27
I don't know teh mechanism of Windows logins, if implemented properly, can't it be made as secure as the login to Windows?
I'm asking because the main point of SaSO was to be able to extend it to other systems that may well be web based, so you don't have to log in to windows first.
The server talks to AD but you can use the same credentials.
We're looking at a project where multiple disparate systems will all have the same username fed from the MIS, but we want ideally the passwords to be centralised, and so ideally from AD.
For the case in point, man in the middle isn't a major issue, putting in another barrier is the requirement. So yes, you're right Windows + L does the same thing.
But if SLT don't even understand the point, or the need for this, if it's SLT you're battling not the teachers, then you might as well give up... or come up with a bit of code as a fun project that puts in a barrier and there is no harm done.
I agree with you @SovietRussia but why if you have a really secure environment where they do already lock their stations do you want to make them sign in to SIMS? If you've reached @matt40k 's utopia environment, then why do you want that barrier. it will use the same sign on, but do it secretly, and save even more time. Just implement trustedauto
13th February 2014, 02:30 PM #28
It's called trusted(auto) mate. It's already present and I personally would\have\do push schools moving towards it. It makes sense to use a central single AD user rather than a separate less secure SQL login. I don't agree with requiring the user to re-authenticate. It's just wrong and makes me annoyed.
Originally Posted by SovietRussia
13th February 2014, 02:35 PM #29
Some times it's fun to make you noyed
13th February 2014, 02:38 PM #30
Doesn't touch the SIMS code at all - it just fires up the exe. It's that simple You could point the config at VLC Media Player if you so wished!
Originally Posted by GREED
I realise that's its strength and weakness - it's just a simple little AD logon executable.
For most schools, SLT approve the policy of locking workstations. People will still forget to. If you're using auto login, that's a problem (though of course they'll often leave SIMS open too, that's another issue). An extra auth layer there could just be a savior - our feedback is that users don't want SIMS to auto-logon without prompt, but they'd like it to use the AD password. In that regard, job done.
But they will do it, and that access will not be taken away. While a fuss can be kicked up, those staff will continue to be given access to that data, as they need it to do their jobs. A staff member's teaching union would kick up a storm if it was any way otherwise.
Originally Posted by matt40k
Thanks to 3s-gtech from:
vikpaw (13th February 2014)
By ceebster in forum Virtual Learning Platforms
Last Post: 18th June 2014, 11:28 AM
By localzuk in forum General Chat
Last Post: 17th July 2008, 10:25 AM
By monkeyx in forum Virtual Learning Platforms
Last Post: 26th November 2007, 08:39 AM
By budgester in forum MIS Systems
Last Post: 21st June 2007, 10:26 AM
By markberry in forum MIS Systems
Last Post: 26th March 2007, 11:27 PM
Users Browsing this Thread
There are currently 1 users browsing this thread. (0 members and 1 guests)