[jira] [Commented] (SLING-3154) Add Topology Message Verification to the Discovery service.
[
https://issues.apache.org/jira/browse/SLING-3154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13790170#comment-13790170
]
Stefan Egli commented on SLING-3154:
I think we might be able to cover both aspects (the whitelist, and the
encrypt/decrypt) with one API - basically provide one hook to 'pack' a payload
for posting and one for 'unpacking' (and thus verifying) upon reception. Eg the
API could be along the following lines:
public interface DiscoveryPayloadHandler {
public RequestEntity pack(String json);
public String unpack(SlingHttpServletRequest request) throws
RejectException;
}
Whereas pack() would be used in the TopologyConnectorClient before posting the
request, and unpack() would be used in the TopologyConnectorServlet when
handling the PUT/DELETE requests. Throwing of the RejectException would imply
ignoring/rejecting the request/announcement.
pack/unpack could be doing encrypt/decrypt/verify - but they could also do
things like gizp for example.
Add Topology Message Verification to the Discovery service.
---
Key: SLING-3154
URL: https://issues.apache.org/jira/browse/SLING-3154
Project: Sling
Issue Type: Improvement
Components: General
Affects Versions: Discovery Impl 1.0.0
Reporter: Ian Boston
Assignee: Ian Boston
Fix For: Discovery Impl 1.0.2
The discovery service provides support for whitelisting sources of topology
information, but in a cluster where the topology this creates a
re-configuration load of order M*(n*(n-1)) where n is the number of nodes in
the topology and M is the number of changes. That load rises rapidly as the
number of changes and/or nodes increases.
To address this there are 2 proposals.
1. To provide an SPI exported from the Discovery Impl bundle that allows
implementors to implement whitelisting based on the request. This will need
to support creating the request and validating the request.
2. Embed functionality within the Discovery Impl bundle that supports
validation and encryption of topology requests.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (SLING-3154) Add Topology Message Verification to the Discovery service.
[ https://issues.apache.org/jira/browse/SLING-3154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13790445#comment-13790445 ] Ian Boston commented on SLING-3154: --- I am thinking of a different approach. Embed everything inside the discovery implementation (it is an implementation after all) and support whitelist or signing with optional encryption of the payload. This should make it much simpler for anyone to configure. Adding a SPI only becomes relevant if the internal impl doesn't cover whats needed, and if there is an SPI, then the impl becomes more complex. Add Topology Message Verification to the Discovery service. --- Key: SLING-3154 URL: https://issues.apache.org/jira/browse/SLING-3154 Project: Sling Issue Type: Improvement Components: General Affects Versions: Discovery Impl 1.0.0 Reporter: Ian Boston Assignee: Ian Boston Fix For: Discovery Impl 1.0.2 The discovery service provides support for whitelisting sources of topology information, but in a cluster where the topology this creates a re-configuration load of order M*(n*(n-1)) where n is the number of nodes in the topology and M is the number of changes. That load rises rapidly as the number of changes and/or nodes increases. To address this there are 2 proposals. 1. To provide an SPI exported from the Discovery Impl bundle that allows implementors to implement whitelisting based on the request. This will need to support creating the request and validating the request. 2. Embed functionality within the Discovery Impl bundle that supports validation and encryption of topology requests. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (SLING-3154) Add Topology Message Verification to the Discovery service.
[ https://issues.apache.org/jira/browse/SLING-3154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13790458#comment-13790458 ] Stefan Egli commented on SLING-3154: Hi [~ianeboston], not quite sure I follow you here. Whitelisting is already supported but if I understand the reason for this ticket correctly, then it was the limited nature of the current whitelisting feature which is not 'enough' - hence, an API (or SPI..) for doing custom whitelisting - as you suggested on the list - to me does make a lot of sense. Or asked differently: how would the whitelisting feature you require for your use case look like (that would be generalizable enough to be put in the discovery.impl)? Regarding encrypting/decrypting: do we have all the APIs on the Sling level for this? Cheers, Stefan Add Topology Message Verification to the Discovery service. --- Key: SLING-3154 URL: https://issues.apache.org/jira/browse/SLING-3154 Project: Sling Issue Type: Improvement Components: General Affects Versions: Discovery Impl 1.0.0 Reporter: Ian Boston Assignee: Ian Boston Fix For: Discovery Impl 1.0.2 The discovery service provides support for whitelisting sources of topology information, but in a cluster where the topology this creates a re-configuration load of order M*(n*(n-1)) where n is the number of nodes in the topology and M is the number of changes. That load rises rapidly as the number of changes and/or nodes increases. To address this there are 2 proposals. 1. To provide an SPI exported from the Discovery Impl bundle that allows implementors to implement whitelisting based on the request. This will need to support creating the request and validating the request. 2. Embed functionality within the Discovery Impl bundle that supports validation and encryption of topology requests. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (SLING-3154) Add Topology Message Verification to the Discovery service.
[ https://issues.apache.org/jira/browse/SLING-3154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13790563#comment-13790563 ] Ian Boston commented on SLING-3154: --- Hi [~egli] I need the ability to have a single shared configuration for an entire topology that allows automated and secure discovery of all active members of that topology without any whitelisting. That configuration should be static and not dependent on the topology itself or reference anything in the physical topology. Regarding encrypting/decrypting: do we have all the APIs on the Sling level for this? I might be missing something but last time I looked the JDK supported encrypting/decrypting. It may not have a huge range of algorithms, but HmacSHA256 and AES/CBC/PKCS5Padding is probably good enough for this. I have working code that doesn't do anything to the existing IP whitelisting unless configured to be active. Best Regards Ian Add Topology Message Verification to the Discovery service. --- Key: SLING-3154 URL: https://issues.apache.org/jira/browse/SLING-3154 Project: Sling Issue Type: Improvement Components: General Affects Versions: Discovery Impl 1.0.0 Reporter: Ian Boston Assignee: Ian Boston Fix For: Discovery Impl 1.0.2 The discovery service provides support for whitelisting sources of topology information, but in a cluster where the topology this creates a re-configuration load of order M*(n*(n-1)) where n is the number of nodes in the topology and M is the number of changes. That load rises rapidly as the number of changes and/or nodes increases. To address this there are 2 proposals. 1. To provide an SPI exported from the Discovery Impl bundle that allows implementors to implement whitelisting based on the request. This will need to support creating the request and validating the request. 2. Embed functionality within the Discovery Impl bundle that supports validation and encryption of topology requests. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (SLING-3154) Add Topology Message Verification to the Discovery service.
[ https://issues.apache.org/jira/browse/SLING-3154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13790633#comment-13790633 ] Ian Boston commented on SLING-3154: --- Changes committed with code coverage for the new code for the passing use cases. Verified no impact on current implementation, as none of the existing tests were touched. All discovery bundles build and pass tests. Will need to deploy so some live instances and configure to validate in the wild. This is a brief description Uses HmacSHA256 with a derived key that lasts 4h for signatures. Uses AES/CBC/PKCS5Padding with a 128 bit key and random 9 byte salt for encryption if enabled. Configuration is via the Config Component. To enable white listing is turned off, a shared key is set and optionally, encryption and the signature key lifetime is set. Signature is performed by performing a HMAC on a SHA of the body, url and direction message (request or response). The SHA is put in X-SlingTopologyHash header, the HMAC is put in X-SlingTopologyTrust header. Verifying the message can be trusted rebuilds checks that the HMAC of the SHA is the same as in the request. No reference is made to the body of the request. When extracting the body of the request or response the SHA is rebuilt and checked against the body of the message (encrypted if the body was encrypted) Encryption takes the String body, and encrypts into a json object with a single key payload containing a JSONArray made up of the base64 encoded 10 byte salt, the Cipher initialisation vector as base64 encoded bytes, and the encrypted data. Decryption uses the salt to generate the key and initialisation vector to decrypt the data. It is possible to replay the same identical message 2x. It is not possible to replay a different message using an old hash/hmac It is not possible to replay an empty message (eg DELETE, where the body is null) on different urls. Requests and responses do not share hash/hmac pairs and both directions are secured. I will leave the issue open in case there objections to this change from the community or if testing turns up issues. Add Topology Message Verification to the Discovery service. --- Key: SLING-3154 URL: https://issues.apache.org/jira/browse/SLING-3154 Project: Sling Issue Type: Improvement Components: General Affects Versions: Discovery Impl 1.0.0 Reporter: Ian Boston Assignee: Ian Boston Fix For: Discovery Impl 1.0.2 The discovery service provides support for whitelisting sources of topology information, but in a cluster where the topology this creates a re-configuration load of order M*(n*(n-1)) where n is the number of nodes in the topology and M is the number of changes. That load rises rapidly as the number of changes and/or nodes increases. To address this there are 2 proposals. 1. To provide an SPI exported from the Discovery Impl bundle that allows implementors to implement whitelisting based on the request. This will need to support creating the request and validating the request. 2. Embed functionality within the Discovery Impl bundle that supports validation and encryption of topology requests. -- This message was sent by Atlassian JIRA (v6.1#6144)
