openbase / bco.authentication Goto Github PK
View Code? Open in Web Editor NEWLicense: Other
License: Other
The authenticator should have a registration mode. This mode last for a few minutes and only if the authenticator is in this mode new password and users can be added.
Registry has to filter which units can be returned to an authenticated client (x/access right).
If the clientId parameter is set to null, set it to the currently logged in user automatically. Saves hassle for the client side application.
Add authentication on every dal.remote.applyAction() request#
Problem: UnitController provide Informers to automatically publish state changes.
Possible solutions:
Public/private key authentication is only implemented for devices so far.
For the initial registration the AuthenticatorController will periodically print a password until the first user is registered. This password is used to decrypt respectively encrypt the hash of the password of the first user.
This user automatically gains admin rights.
This only happens when a client is registered within the application. E.g. when there is a client in the CredentialStore of the application.
userID@clientID
Currently, the AuthenticatorController holds static session keys. These should be replaced by the session key retrieved from the CST.
The client remote for the authentication is needed in many places but this can all be handled by a cashed version.
This is necessary because the registry remotes could also make use of that to filter by the user which is currently logged in.
Is needed for openbase/bco.registry#44.
SessionManager.isAuthenticated() sends request to the AuthenticationController to see if the provided ClientServerTicket is still valid.
If so, a valid CST is sent back and saved in SessionManager which returns true to the client application (e.g. BCozy).
If not, CST and sessionKey are unset in SessioManager which returns false to the client application.
Security feature: When a user fails to login multiple times, send a notification to the admins.
Which permissions should be considered/preferred, in case a user logged in on a registered client and the client has more permissions than the user?
In case the client's permissions should be preferred, as of now the system would have to manage two ClientServerTickets in parallel, because both client and user would have to be authenticated.
In case the user's permissions should always be preferred, no matter if they're lower than the client's or not, nothing would have change. If a user is logged in, it's permissions would always be checked. In case no user is logged in, the client's permissions would be checked.
Register a client or user in the system
This is needed for the login step.
The password store would store the
The password store would store those permanently. There would be dedicated fields for each parameter, e.g. the client's public key would not be stored in the password field that's dedicated for the user's password.
Instead of the current solution with the initial password, we now prefer to register an initial admin account in the registry and the authentication storage.
Make sure that there is always at least one admin left in the system, that is an admin cannot remove himself
Passwords / public keys should not be stored in the Registry, but in a dedicated storage for the authentication component. The directory has to be protected accordingly.
Please make sure your code compiles well before you commit it to any master branches.
Please use feature branches if you want to work together on complex code changes where the build can not be guaranteed.
Please solve the compiler issues mentioned by travis:
I am not sure if there already exists such an issue so I create this one to reference it from within others.
As long as controller just publish their data when it changes, read rights are useless because everyone who is willing to listen will get the current state.
One possible solution to this would be that controller just notify that their data has changed and remotes will then start a request with their specific rights. A disadvantage of this is that it produces a lot of overhead communication for a simple data update.
The authentication should be as simple to use as possible. Thus the current methods should be encapsulated as:
Rename:
AuthenticatorTicket --> TIcketAuthenticatorWrapper
LoginResponse --> TicketSessionKeyWrapper
The AuthenticatorController should not only update the validity period of a ClientServerTicket, but also the timestamp of the Authenticator. The client has to check this change to make sure that the correct AuthenticatorController responded.
Currently the methods used for authentication just throw a RejectedException. Thishas to be enhanced so that it is clear what went wrong and what the client has to do to fix it.
E.g. differentiate between incorrect password and user not found
If multiple threads share a single SessionManager, a situation can occur where a thread after a long computation sets the updated ticket, which is then older than the ticket that has been set in the meantime by another thread.
Is it possible and reasonable to realize Kerberos authentification via RSB?
Implement a test case with components communicating over RSB.
An administrator should be able to set the administrator flag of other users
Notes:
Some users should have the permission to change passwords for others.
In our current meeting we identified a huge safety problem in our current approach. Currently as action is sent to a UnitController containing authorization information. The UnitController contacts the AuthenticationController and performs the action. Then the verification of the answer of the AuthenticationController is performed by the remote. The Problem is that the UnitController performs the action but the verification of the answer of the AuthenticationController is done afterwards. So anybody could answer the request by the UnitController and it would perform the action.
We identified 2 possible solutions:
Every UnitController has to be logged in as a client. This way he can be sure that the correct AuthenticationController responds. However this produces a lot of overhead for simple requests and registering every UnitController as a client would be a lot of work.
The AuthenticationController is part of every component that has to verify if a user is logged in. The problem with this solution is that it gets quite complicated if bco is started distributed on more than one machine because the AuthenticationStore has to be synchronized somehow and you would have to log in with each AuthenticationController separately.
Wie am Mittwoch schon erwähnt, hat die JSON-Serialisierung von Protobuf auf ByteStrings mit einzelnen Bytes Probleme. Namentlich werden \a
zu a
und \v
zu v
serialisiert, was natürlich bei der nächsten Deserialisierung zu einem anderen Ergebnis führt. Ich habe jetzt nochmal eine ganze Weile nach Lösungen gesucht, aber keine wirklich guten für Protobuf 2 gefunden. Protobuf 3 kann das, aber wir können ja nicht einfach auf 3 umstellen. Da wir die einzigen sind, die bytes in RST-Typen verwenden, betrifft das wohl auch nur uns.
Mein Lösungsvorschlag wäre, die credentials in LoginCredentials zu einem String zu machen. Byte-Arrays können als Base64-String gespeichert und geparst werden. Das muss auch nur in der AuthenticationRegistry geändert werden, da die LoginCredentials außerhalb nicht verwendet werden.
Unsere anderen Datentypen, in denen wir bytes verwenden, sollten keine Probleme verursachen, da wir sie nicht zu JSON serialisieren.
Kannst du RST dann morgen neu bauen @pLeminoq? Es sei denn natürlich, ihr habt andere Lösungsvorschläge.
ATM, we set an empty string for the client's IP address inside the various Kerberos tickets.
Edit: The 2nd point should be managed by the client's application, since the method for saving user data is dependent on the software being used by the client's application. As of now the sessionManager uses a credentialStore to solely store the client's id and private key - nothing else
Edit: User's id and password are saved for a session, if user wished so. Relog does also work for user who wished for saving his data temporarily.
Used for clients that should have special rights.
When starting BCozy, BCO prints error messages like this one:
ERROR o.o.b.m.a.c.p.PowerStateSynchroniserAgent ═╦═⚀ org.openbase.jul.exception.CouldNotPerformException: Could not invoke Method[Class applyAction(ActionDescription)]!
ERROR o.o.b.m.a.c.p.PowerStateSynchroniserAgent ╚══╦═⚀ Could not invoke Method[Class applyAction(ActionDescription)]!
ERROR o.o.b.m.a.c.p.PowerStateSynchroniserAgent ╚══╦═⚀ InvocationTargetException
ERROR o.o.b.m.a.c.p.PowerStateSynchroniserAgent ╚══╦═⚀ Could not apply action!
ERROR o.o.b.m.a.c.p.PowerStateSynchroniserAgent ╚══╦═⚀ Could not execute action!
ERROR o.o.b.m.a.c.p.PowerStateSynchroniserAgent ╚════⚀ You have no permission to execute this action.
ERROR o.o.b.m.a.c.p.PowerStateSynchroniserAgent =====================================
and the same for StandbyAgent
.
Clients should be able to login via a private/public key pair
current Implementation supports that but:
Clients might have permissions and groups, like users do.
Proposed pipeline:
if logged in:
check user permissions
else:
if client has specific permissions for this unit:
check client permissions
else:
check other permissions
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.