fix: Add authorization check for enrollment in lookup verb handler

[sitaram-kalluri]

- What I did

• When user is authenticated vai the APKAM mechanism, when executing lookup verb, verify if the user has authorization to the key's namespace.
• Refactor lookup_verb_handler.dart to increase the readability.
• Update the tests in scan_verb_test.dart. Populated enrollmentId to the inbound connection to mimic the connection is authenticated via the APKAM and authorization check for namespaces enrolled is performed.

- How I did it

• When user authenticates via the APKAM mechanism, fetch enrollmentId from the connection metadata. Retrieve the enrolled namespaces and verify if user has permission for the key's namespace. If yes, return the data; else throw UnAuthorizedException.
• Refactor 'Lookup_verb_handler.dart'

- How to verify it

• Add unit tests in lookup_verb_test.dart to assert the APKAM enrollment changes. Ran all unit tests and functional tests in local and tests pass.
• Add following scenario in scan verb unit test - A test to verify scan returns all keys when enrollment has *:rw access

- Description for the changelog

[gkc]

In addition to my comment on the verb handler implementation, I have one more question - are there tests which cover 'special' records? (1) 'reserved' keys (2) shared symmetric keys (shared_key.bob@alice and @bob:shared_key@alice) etc?

[sitaram-kalluri]

In addition to my comment on the verb handler implementation, I have one more question - are there tests which cover 'special' records? (1) 'reserved' keys (2) shared symmetric keys (shared_key.bob@alice and @bob:shared_key@alice) etc?

Regarding the reserved keys, particularly the key format "@bob:shared_key@alice", when a user authenticates via the APKAM (who has full access), the absence of a namespace associated with the key leads to the failure of the authorization check. As a result, the data retrieval process does not succeed. One approach to deal with this is to have a system level namespace for all the reserved keys.
@gkc: Can you please share your thoughts on this?

[gkc]

In addition to my comment on the verb handler implementation, I have one more question - are there tests which cover 'special' records? (1) 'reserved' keys (2) shared symmetric keys (shared_key.bob@alice and @bob:shared_key@alice) etc?

Regarding the reserved keys, particularly the key format "@bob:shared_key@alice", when a user authenticates via the APKAM (who has full access), the absence of a namespace associated with the key leads to the failure of the authorization check. As a result, the data retrieval process does not succeed. One approach to deal with this is to have a system level namespace for all the reserved keys. @gkc: Can you please share your thoughts on this?

I suggest that if a record id has no namespace then we should say that the client is authorized. This is not an absolute rule - this rule should be applied any broader permission checks (e.g. records which are protected from deletion, immutable checks when we have immutable records, etc)

[sitaram-kalluri]

In addition to my comment on the verb handler implementation, I have one more question - are there tests which cover 'special' records? (1) 'reserved' keys (2) shared symmetric keys (shared_key.bob@alice and @bob:shared_key@alice) etc?

Regarding the reserved keys, particularly the key format "@bob:shared_key@alice", when a user authenticates via the APKAM (who has full access), the absence of a namespace associated with the key leads to the failure of the authorization check. As a result, the data retrieval process does not succeed. One approach to deal with this is to have a system level namespace for all the reserved keys. @gkc: Can you please share your thoughts on this?

I suggest that if a record id has no namespace then we should say that the client is authorized. This is not an absolute rule - this rule should be applied any broader permission checks (e.g. records which are protected from deletion, immutable checks when we have immutable records, etc)

Sure Gary.

[gkc]

LGTM

[gkc]

@sitaram-kalluri Before I approve and merge this, please run this server locally and run the at_talk program with 'new' atSigns alice and bob, and verify that everything is working correctly. Please also do any other client program testing that is appropriate.

[sitaram-kalluri]

@sitaram-kalluri Before I approve and merge this, please run this server locally and run the at_talk program with 'new' atSigns alice and bob, and verify that everything is working correctly. Please also do any other client program testing that is appropriate.

Sure Gary.

[sitaram-kalluri]

@sitaram-kalluri Before I approve and merge this, please run this server locally and run the at_talk program with 'new' atSigns alice and bob, and verify that everything is working correctly. Please also do any other client program testing that is appropriate.

Sure Gary.

• Tested with at_talk and below send and receive messages. Attaching the recording.
• Functional tests and E2E tests ran succesfully.

at_talk_test.mp4