At the university where we are studying, we are developing a Java EE system to debure some of the registration processes, extinguish forms and generate PDF forms that instead of literally passing by hand, will pass through person in person. First we think like this, let's create a button, if the employee (who can be a teacher, a director of a center, etc.) click on defer (as if he signed) is because he is deferred and ready, but what if someone asks for some proof that really Did he grant such an inscription? How to prove? How can we ensure that only the employee will make a deferment? Considering that the same can access the system from any computer / smartphone, anywhere, the only restriction is that it will have a period in the specific month to make such deferment.
How to ensure that the person who used the system is really it?
3 answers
What if someone asks for some proof that it really was him who granted such an application?
The name of this characteristic you are looking for is non-repudiation ( non-repudiation ). It is one of the characteristics that cryptographic systems often seek to achieve (the others being confidentiality , authenticity and integrity ).
Before commenting on the "hard" ways to ensure non-repudiation, I would like to say that I agree with the other replies and comments: if you trust employees and IT staff at your university (ie is not concerned with example with some system administrator manually entering a deferment on behalf of a teacher without authorization), then it is all a matter of authentication and authorization:
- Establish your credential policies to reduce the risk of someone misusing your teacher account (for example, requiring strong passwords - but memorable - some more form of second factor ). In my college, for example, we received a paper with a list of PINs, and for each "sensitive" action in the system we had to insert one of them, even though it was already logged in. This used PIN was no longer reused for nothing.
- Ensure that your application establishes authorization rules correctly (ie ensure that only users in the "teachers" group have access to the "defer" feature).
If, on the other hand, you need a stronger guarantee, then we go into solutions of a technical nature. Some people have suggested biometrics, seriously or humorously, but the fact is that biometrics is for authentication , not for non-repudiation. Worse, biometrics alone is not so good to authenticate: if you leave an unsupervised door with a retina reader on the side, where you just have to look for the door to open, approximately 7000 people could look at it and the system identifies Biometrics only work if it is accompanied by other factors (eg, you show a document to an employee - if identifying ) - and then look at retinal reader - authenticating ). This answer in security.SE shows more details.
The most widely used medium for non-repudiation is the digital signature. Let's say that each teacher creates for himself / herself a digital certificate (where he himself established the private key - if it was the very faculty that provided that to him, non-repudiation does not apply) on your system. The university itself can be the Certifying Authority, or in even more formal cases one can use for example the services of ICP-Brasil - whose digital signatures have by law the same validity of the "normal" signatures in this country. This certificate can be on the user's own computer (less secure) or on a smartcard (more secure).
It is the responsibility of the user to ensure the security of their certificate, not to allow their private key to be accessed by third parties. And / or notify the university immediately if it is suspected that it has been compromised. In these conditions, assuming that only the teacher has access to his private key, it is enough to make his critical actions in the system have to be digitally signed by him. Thus, while ensuring its integrity and authenticity (ie no one can tamper with the content without invalidating the signature, and no one can sign for it) if there is also non-repudiation (if the signature is there, there is no way to it deny that he signed it.)
Again, I am giving this information in order to make the complete answer: this whole paraphernalia has a negligible cost (if not money, but inconvenience for users), and should not be used unless really required. In 99% of cases it is overkill , and simple trust in system administrators is enough to turn authenticity into non-repudiation ("it is registered in the database that the X action was executed by user Y, period final ").
I see that the only way is with a login, as it is a university everyone has to have their RA registered in the entity ie you should use this to authenticate them as there should also be a password, what comes to mind is you request an email for each student so that this one receives your password or that they sign their password at the university in front of the presentation of the school card.
Unfortunately without this I do not see how to authenticate these people with security and integrity
It is necessary to know how hardcore you want to be to really ensure that it is certain person.
CASE 01: in a vote really needs to be it.
Solution: Biometric Reader.
CASE 02 : Access to a page (example bank sites)
Solution: Token or SMS code
CASE 03: Accessing a page
Solution: Access in 2 or 3 steps, the 2nd and 3rd step can vary with Password, Secret question, registration data, etc.
More Information (links):