Hi Rami,
I'm sorry this is not working for you!
To establish a baseline, can you try testing the 1.3.0 version of the two
secure apps, and see whether they work similarly to yours?
in <iotivity>/out/linux/x86_64/debug/resource/csdk/stack/samples/linux/secure
dir:
$ ./ocserverbasicops |& tee server.log
In another console (same dir):
$ ./occlientbasicops -t 2 -d 0 |& tee client-non-devowner.log
Or
$ ./occlientbasicops -t 2 -d 1 |& tee client-devowner.log
If you search the server.log file you can find messages showing the processing
of the incoming request and ACCESS_GRANTED based on the /acl2 entry in the
oic_svr_db_server.dat/.json file. E.g. (from the server.log, using the
non-devowner client args):
"34:41.048 DEBUG: OIC_SRM: Received request from remote device
34:41.048 INFO: OIC_SRM_PE: GetPermissionFromCAMethod_t: CA method 2 requires
permission 0x4
34:41.048 DEBUG: OIC_SRM: ctx->subjectUuid for request:
31393139-3139-3139-3139-313931393139.
34:41.048 DEBUG: OIC_SRM: CA_SECURE flag is set; indicates secure channel.
34:41.048 DEBUG: OIC_SRM: SetDiscoverable: resource /a/led is OC_DISCOVERABLE.
34:41.048 DEBUG: OIC_SRM: Processing request with uri, /a/led for method 2
34:41.048 DEBUG: OIC_SRM_UTILITY: UuidCmp: returning false.
34:41.048 DEBUG: OIC_SRM_UTILITY: UuidCmp: returning false.
34:41.048 DEBUG: OIC_SRM_PE: Owner UUID :
34:41.048 DEBUG: OIC_SRM_PE: 32 32 32 32 32 32 32 32 32 32 32 32 32 32 32 32
34:41.048 DEBUG: OIC_SRM_PE: Request UUID:
34:41.048 DEBUG: OIC_SRM_PE: 31 39 31 39 31 39 31 39 31 39 31 39 31 39 31 39
34:41.048 DEBUG: OIC_SRM_PE: IsRequestFromDevOwner: request was NOT received
from device owner
34:41.048 DEBUG: OIC_SRM_UTILITY: UuidCmp: returning false.
34:41.048 INFO: OIC_SRM_PE: IsRequestFromResourceOwner: returning false
34:41.048 DEBUG: OIC_SRM_PE: Entering ProcessAccessRequest(/a/led)
34:41.048 DEBUG: OIC_SRM_ACL: IN: GetACLResourceDataByConntype(0)
34:41.048 DEBUG: OIC_SRM_PE: ProcessAccessRequest: found conntype auth-crypt
match; processing for access.
34:41.048 DEBUG: OIC_SRM_PE: ProcessMatchingACE: found ACE matching subject.
34:41.048 DEBUG: OIC_SRM_PE: ProcessMatchingACE: Searching for resource...
34:41.048 DEBUG: OIC_SRM_ACL: IN: GetACLResourceDataByConntype(0)
34:41.048 DEBUG: OIC_SRM_ACL: OUT: GetACLResourceDataByConntype(0)
34:41.048 INFO: OIC_SRM_PE: ProcessAccessRequest:no ACL found matching conntype
auth-crypt for resource /a/led
34:41.048 DEBUG: OIC_SRM_ACL: GetACLResourceData: searching for ACE matching
subject:
34:41.048 DEBUG: OIC_SRM_ACL: 31 39 31 39 31 39 31 39 31 39 31 39 31 39 31 39
34:41.048 DEBUG: OIC_SRM_ACL: GetACLResourceData: found matching ACE:
34:41.048 DEBUG: ACL_LOG: =================================================
34:41.048 DEBUG: ACL_LOG: ACE @ 0x8a2f50
34:41.048 DEBUG: ACL_LOG: aceid = 4
34:41.048 DEBUG: ACL_LOG: permission = 0x7
34:41.048 DEBUG: ACL_LOG: subject UUID =
31393139-3139-3139-3139-313931393139
34:41.048 DEBUG: ACL_LOG: resources[0]:
34:41.048 DEBUG: ACL_LOG: href = /a/led
34:41.048 DEBUG: ACL_LOG: =================================================
34:41.048 DEBUG: OIC_SRM_PE: ProcessMatchingACE: found ACE matching subject.
34:41.048 DEBUG: OIC_SRM_PE: ProcessMatchingACE: Searching for resource...
34:41.048 DEBUG: OIC_SRM_PE: IsResourceInAce: found href /a/led matching
resource.
34:41.048 INFO: OIC_SRM_PE: ProcessMatchingACE: found matching resource in ACE.
34:41.048 INFO: OIC_SRM_PE: IsPermissionAllowingRequest: ACE allows permission
0x7, requested permission 0x4 -> allowed = 1
34:41.048 INFO: OIC_SRM_PE: ProcessAccessRequest: returning with responseVal =
ACCESS_GRANTED
34:41.048 DEBUG: OIC_SRM: Request for permission 4 received responseVal 1.
34:41.048 INFO: OIC_SRM: SRMGenerateResponse : entering function.
34:41.048 INFO: OIC_SRM: SRMGenerateResponse : Access granted, passing req to
endpoint."
Note: there *will* be "OC_STACK_UNAUTHORIZED_REQUEST" responses received by the
Client, as part of the test apps involves sending requests for which the Client
doesn't have permissions, to make sure they are properly rejected.
If your apps aren't having this same success, please compare your .json to the
example .json files in the same dir as these apps. You'll need to verify that
both devices have a /cred entry for one another, just like the samples, and
that the UUID of the Client matches a /cred entry, as well as an /acl2 entry,
giving the Client both the ability to authenticate connect securely, and the
authorization to access the /a/led Resource.
Your Server should be creating the Resource with the OC_SECURE and
OC_DISCOVERABLE flags, e.g.:
OCStackResult ret = OCCreateResource(&gPstatHandle,
OIC_RSRC_TYPE_SEC_PSTAT,
OC_RSRVD_INTERFACE_DEFAULT,
OIC_RSRC_PSTAT_URI,
PstatEntityHandler,
NULL,
OC_SECURE |
OC_DISCOVERABLE);
Hope this is helpful; good luck. I'm going to be out tomorrow and Monday but
if you continue to have trouble hopefully someone else can help. If not, I'll
try to reply again when I get back Tuesday.
Thanks,
Nathan
From: iotivity-dev-bounces at lists.iotivity.org
[mailto:[email protected]] On Behalf Of rami alshafi
Sent: Thursday, June 15, 2017 4:54 PM
To: i.mushfiq at samsung.com
Cc: iotivity-dev at lists.iotivity.org
Subject: Re: [dev] Help needed with resource secure restricted access
The default dat file does not restrict the access to the secure resources. In
fact, the Led resource is not even defined in the default dat file.
I have verified that there is no issue with the json2cbor tool as I converted
the dat file back to json and compared its content to the original json file.
Thank you very for your reply. I hope others could contribute to help me out on
this issue.
Thanks,
-Rami
________________________________
From: Muhammad Mushfiqul Islam <i.mushfiq at
samsung.com<mailto:[email protected]>>
Sent: Wednesday, June 14, 2017 8:56:26 PM
To: rami alshafi
Cc: iotivity-dev at lists.iotivity.org<mailto:iotivity-dev at
lists.iotivity.org>
Subject: RE: Re: [dev] Help needed with resource secure restricted access
Hello,
Have you tried with the default dat file?
For me, the default dat file works fine.
Probably there is a problem in the conversion app(json2cbor)
A patch have been submitted for json2cbor:
https://gerrit.iotivity.org/gerrit/20539/
Can you please try with this patch? I will also try with this patch when I have
time.
- Thanks & Regards,
Mushfiqul Islam Antu
--------- Original Message ---------
Sender : rami alshafi <rami_in_portland at hotmail.com<mailto:rami_in_portland
at hotmail.com>>
Date : 2017-06-15 05:04 (GMT+6)
Title : Re: [dev] Help needed with resource secure restricted access
To : null<iotivity-dev at lists.iotivity.org<mailto:iotivity-dev at
lists.iotivity.org>>
I have not received any replies. i would appreciate any help in this regard.
Thanks,
-Rami
________________________________
From: iotivity-dev-bounces at lists.iotivity.org<mailto:iotivity-dev-bounces at
lists.iotivity.org> <iotivity-dev-bounces at
lists.iotivity.org<mailto:iotivity-dev-bounces at lists.iotivity.org>> on
behalf of rami alshafi <rami_in_portland at
hotmail.com<mailto:[email protected]>>
Sent: Wednesday, June 7, 2017 2:55:22 PM
To: iotivity-dev at lists.iotivity.org<mailto:iotivity-dev at
lists.iotivity.org>
Subject: [dev] Help needed with resource secure restricted access
Hi Developers,
I need help restricting access to a secure resource. I am running the
sampleserver_justworks secure server application with a secure led resource
that can run without issues with anonymous subjects. However, when I restrict
the access of the secure led to a specific subject uuid then I can no longer
access the secure led resource even though the client application has its
subject uuid matching the one allowed by the access control entry hosting the
secure led resource. I keep getting "OS_STACK_UNAUTHORIZED_REQ" response. I
have attached the json files that I used to after converting them to cbor along
with the text copy of the code of both applications and the logs.
I would appreciate the help. From what I can tell, the problem seems to be when
the IsRequestFromDevOwner() function (in policyengine.c) returns false because
the requestInfo.info.identity.id is not updated with the client's subject uuid
which is what the Policy Engine uses to update its context and eventually used
to compare it with the allowed subject uuid defined by the ACE hosting the
secure led.
Another theory is that the fact the communication channel is not secure because
the CA_SECURE is not set, which I have no idea how to set. If anyone know how
to set it to true, please let me know.
Thanks
_______________________________________________
iotivity-dev mailing list
iotivity-dev at lists.iotivity.org<mailto:iotivity-dev at lists.iotivity.org>
https://lists.iotivity.org/mailman/listinfo/iotivity-dev
[cid:image001.gif at 01D2E620.41AD3CE0]
[http://ext.samsung.net/mail/ext/v1/external/status/update?userid=i.mushfiq&do=bWFpbElEPTIwMTcwNjE1MDM1NjI2ZXBjbXMxcDYxYzlhZmE2OTRkMjk0OWVhMTJlZDU1NzFjYzBlNTAwOSZyZWNpcGllbnRBZGRyZXNzPXJhbWlfaW5fcG9ydGxhbmRAaG90bWFpbC5jb20_]
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.iotivity.org/pipermail/iotivity-dev/attachments/20170616/93352347/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.gif
Type: image/gif
Size: 13402 bytes
Desc: image001.gif
URL:
<http://lists.iotivity.org/pipermail/iotivity-dev/attachments/20170616/93352347/attachment.gif>
