atsign-foundation / at_client_sdk

The Dart implementation of atSDK used for implementing Atsign's technology into other software
https://pub.dev/publishers/atsign.org/packages
BSD 3-Clause "New" or "Revised" License
1.47k stars 32 forks source link

APKAM - namespace authorization for at_client methods #1269

Closed murali-shris closed 1 month ago

murali-shris commented 3 months ago

Is your feature request related to a problem? Please describe.

Describe the solution you'd like

Describe alternatives you've considered

No response

Additional context

No response

murali-shris commented 3 months ago

Raised a draft PR to apkam feature branch https://github.com/atsign-foundation/at_client_sdk/pull/1279

murali-shris commented 2 months ago

PR under review https://github.com/atsign-foundation/at_client_sdk/pull/1297

murali-shris commented 2 months ago

PR under review #1297

investigating failure in functional test

sitaram-kalluri commented 2 months ago

@gkc: To implement client-side authorization checks, the client needs to have enrollment information stored in its keystore. As a fallback option, if the client doesn't have the enrollment details(e.g user authenticates using.atKeys in legacy manner on another device) we have to fetch the details from server.One approach is by extending the "enroll:list" command to optionally accept an enrollment ID. If this ID is provided, the server will return the enrollment details associated with that ID.

Please share your thoughts on this approach?

gkc commented 2 months ago

@sitaram-kalluri Where does the client currently get its enrollment info? (i.e. the namespaces to which it has access?)

sitaram-kalluri commented 2 months ago

@sitaram-kalluri Where does the client currently get its enrollment info? (i.e. the namespaces to which it has access?)

When an enrollment is approved, the requesting application fetches the information from the enrollment keychain and writes it to the local storage. These changes are in "apkam_authorization_changes" branch in at_client.

However, the above approach fails in the following cases:

When onboarding an atsign for first time: When an atsign is onboarded for the first time, the enrollment request is generated in the at_auth package and sent to the server. Since the client didn't initiate the enrollment, it doesn't have any information about it in its local keychain.

Authenticating an atsign atKeys File: When an atsign is authenticated using an atKeys file, the local secondary storage or the key-chain will not have the enrollment information to write to the local storage.

gkc commented 2 months ago

Thank you. I suggest enroll:fetch:

sitaram-kalluri commented 2 months ago

Thank you. I suggest enroll:fetch:

Thank you. Sure, will add a fetch operation to enroll verb which returns the enrollment information.

sitaram-kalluri commented 2 months ago

Completed the implementation of enroll:fetch to get the enrollment information. The changes are released into production in v3.0.44. Pending work in current sprint is to get the enrollment information and do an authorization check.