Repository navigation
Does secure field in ServiceRegistryRequestDTO and other places identify an access policy? #198
Description
There are three secure modes that I'm aware of, NOT_SECURE, CERTIFICATE and TOKEN.
It seems to me as if CERTIFICATE and TOKEN identify two kinds of service access policies. The first one implies that a consuming system will be granted access if it has the correct kind of certificate, while the second implies that access is granted if a correct token can be presented. Of course these descriptions are oversimplifications, but it brings us to my point. The naming.
If the secure field really is identifying some kind of access policy, shouldn't the name of the field be accessPolicy? Also, I propose that the following names be used for the different policies:
UNRESTRICTEDinstead ofNOT_SECURE. Of course this policy is still not permitted for systems running in secure mode.SAME_CLOUD, or perhaps onlyCLOUD, instead ofCERTIFICATE.TOKENremains.
I believe the advantage of the naming is two-fold: (1) it communicates that the identifiers are about controlling access and not about controlling what security mechanisms will be used (that is decided already at the system level, if I'm not mistaken?) and (2) it opens up for discussing if there are other access policies that should be supported by arrowhead, such as SAME_COMPANY or SAME_MASTER.
Activity
emanuelpalm commentedon Mar 25, 2020
Another set of suitable names could perhaps be:
ALL(NOT_SECURE)UNRESTRICTEDMASTERCOMPANYCLOUDTOKENtsvetlin commentedon Apr 17, 2020
Great idea!
I think
ALLis ambiguous, I'd go withUNRESTRICTED.Is
MASTERnecessary? Every cloud certificate is created by the root arrowhead.eu certificate, so that part can't change, only the company and cloud parts in the certificate (my_client.my_cloud.my_company.arrowhead.eu).emanuelpalm commentedon Apr 20, 2020
I agree that
UNRESTRICTEDis a better name.@tsvetlin If
MASTERis necessary depends on whether multiple masters will be allowed or not, or if having a master is optional. If all Arrowhead certificates must be issued by the Arrowhead master, then there is, of course, no need. I'm not so sure, however, if forcing that is a good idea. I can't think of any good use case right now, so perhapsMASTERshould be omitted for version 5.0 and be brought back later if the need would arise?tsvetlin commentedon Apr 20, 2020
Using different Master certificates would break the chain of trust. Thats why it is one. Of course, later this can change. For now I think
MASTERshould be omitted, and implemented when it is needed.mzsilak commentedon Apr 20, 2020
@tsvetlin As far as I remember, the debian installation allows the creation of their own master certificate already.
rbocsi commentedon Apr 20, 2020
@mzsilak Yeah, it's true, and it called that installation mode DETACHED for this reason.
jerkerdelsing commentedon May 15, 2021
I do agree with the direction of the proposals. Seams to be much in line with the interoperability strategy. What could be looked at is which security policy thinking and naming different protocols are using. The same goes for other "cloud" frameworks, LwM2M @jenseliasson , IoTivity, Amazon, Aszure, ....