Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

DefaultAuthorizer behavior discussion #1663

Open
sbernard31 opened this issue Oct 23, 2024 · 0 comments
Open

DefaultAuthorizer behavior discussion #1663

sbernard31 opened this issue Oct 23, 2024 · 0 comments
Labels
discussion Discussion about anything server Impact LWM2M server

Comments

@sbernard31
Copy link
Contributor

This issue aims to discuss about current DefaultAuthorizer behavior.
This idea is to know if it is OK or should be changed.

Sorry this is not a too simple topic. I try to summarize at my best. To not hesitate to ask question if needed !

Current Behavior

Currently, DefaultAuthorizer is only used on Register, Update, Deregister request and each time, it checks identity based on SecurityInfo in security store. (See : https://github.com/eclipse-leshan/leshan/blob/leshan-2.0.0-M16/leshan-lwm2m-server/src/main/java/org/eclipse/leshan/server/security/DefaultAuthorizer.java#L48-L59)

Not so consistent ?

What is the consequence of this behavior ? if the SecurityInfo changed in security store then

  • Register/Update/Deregister request will be rejected.
  • other exchange (e.g. Server sending a Request OR notification received) this will be accepted.
  • we also have 2 out of LWM2M scope feature which allow to do a kind of Update on Send or Notification, they will be accepted too.

☝️ that sounds not to much consistent 🤔

Recent changes

Recently, I create a new PRs (#1655, #1656) who make DefaultAuthorizer behavior a bit more complex.
Now it also check that same endpoint uri is used for given registration.
E.g. : If I have 2 server endpoint : coap://locahost:5683 and coap://locahost:5783 if you register on the first one and try to update on second one you will be rejected.
And also for Send that identity doesn't change.

See : DefaultAuthorizer

Some more information

Note that a Registration contain the current Identity used.

Note that, if you change SecurityInfo and you want that corresponding credential will not be used anymore, you can remove security info saying that credentials is compromised, so (D)TLS layer should do their best to delete connection/session related to it.

Note also that ensuring security matching between Request and Response is delegate to under layer.

Questions !

  • Is it a good behavior ?
  • Can we find a more simple and consistent way ?

I don't know maybe we check only security store at Register then for all other we just check that identity doesn't change ?
Consequences :

  1. a client need to reregister if it change its credentials.
  2. if security info is changed in security store then we will not rejected Update or DeRegister request ?

For 2. we can imagine that we remove Registration with identity related to changed/removed securityInfo ?

@sbernard31 sbernard31 added server Impact LWM2M server discussion Discussion about anything labels Oct 23, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
discussion Discussion about anything server Impact LWM2M server
Projects
None yet
Development

No branches or pull requests

1 participant