openbase / bco.authentication Goto Github PK

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#

• add the same instance of sessionManager to every remote in remote.unit.Units
• call authentication.lib.AuthenticatorClientHandler.initSSRequest() and ~.handleSSResponse() in dal.remote.unit.AbstractUnitRemote.applyAction() before and after every request
• implement authentication.lib.clientRemote.requestCST in dal.lib.unit.AbstractUnitController before performing a task

Problem: UnitController provide Informers to automatically publish state changes.
Possible solutions:

1. Informers only publish state changes that are visible for the public.
2. Informers publish that there are changes, remotes have to pull detailled information about what changed, filtered by permission.

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.

• Login using 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.

Already done by commits:

• 2242919
• 141a531

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

• assume an admin who has the rights to do this already exists
• register a user with his password and a flag indicating if he is an admin or not
• register a client with his public key and a flag indicating that he is not an admin by default

This is needed for the login step.

The password store would store the

1. client's id, private and public key (maybe rather only their components to later rebuild the keys)
2. user's id, password and keep-logged-in-flag

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:

• https://travis-ci.org/openbase/bco.authentication
• https://s3.amazonaws.com/archive.travis-ci.org/jobs/242544847/log.txt?X-Amz-Expires=30&X-Amz-Date=20170613T193612Z&X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AKIAJRYRXRSVGNKPKO5A/20170613/us-east-1/s3/aws4_request&X-Amz-SignedHeaders=host&X-Amz-Signature=ab23789f7d642f999dcfb2132f160fbdf761485ffafb2983cb1afbeaa2d90ca8

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:

• login()
• logout()

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:

• he should not be able to set the flag of himself
• either of non existent users

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.

• Always do this for clients, no exceptions so far.
• Only do this for users, if keep-logged-in-flat is set. Keep in mind: this flag only applies for the current application session. If the application is restarted then the user should always be urged to log in again manually.

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:

• does not use any password / key pair store on the client side yet
• does not save the client's private key in the mock authentication

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