(Created page with "= DRAFT = Conditions: * Since publishing "FCM HTTP v1" Google improved security system of their FCM services. Now it requires to use short-time access tokens from OAuth 2.0...")
 
(Terminal requests BM to register push-channel)
 
(40 intermediate revisions by the same user not shown)
Line 1: Line 1:
 
= DRAFT =
 
= DRAFT =
  
 
+
== Conditions ==
Conditions:
+
* Since publishing "FCM HTTP v1" Google improved security system of their FCM services. Now it requires to use short-time access tokens of OAuth 2.0 service, which uses private key based authentication and specific Google software libraries.
* Since publishing "FCM HTTP v1" Google improved security system of their FCM services. Now it requires to use short-time access tokens from OAuth 2.0 service, which uses private key based authentication and specific Google software libraries.
+
 
* Each terminal vendor has it's own application with it's unique Application ID registered and Google Firebase. Terminal may have several applications with different IDs. It should not be a good idea to hardcode Application IDs inside BM's code as well as vendor's private key to pass Google Authentication.
 
* Each terminal vendor has it's own application with it's unique Application ID registered and Google Firebase. Terminal may have several applications with different IDs. It should not be a good idea to hardcode Application IDs inside BM's code as well as vendor's private key to pass Google Authentication.
 
* Due to real-time nature of the service all messages should be sent by BM directly. This should solve issues of inaccessability of service and power of vendor's site.
 
* Due to real-time nature of the service all messages should be sent by BM directly. This should solve issues of inaccessability of service and power of vendor's site.
  
 
+
== Assumptions ==
Assumptions:
+
* When terminal goes to the idle mode it may pass IDLE message to BM contains info about Vendor's service which will provide information to pass messages to FCM such as application identifiers, access token and expiration time.
* When terminal goes to the idle mode it may pass IDLE message to BM contains info about Vendor's service which will provide information to pass messages to FCM such as application-id, access-token, expiration-time.
+
* On this way terminal vendor delegates message sending feature to BM without disclosing information of its private key.
* On this way terminal vendor delegates message sending feature to BM without disclosing information of its private keys.
+
 
* BM / Registry will store these data and assosiate it with particular terminal / connection context and use it to wake application up.
 
* BM / Registry will store these data and assosiate it with particular terminal / connection context and use it to wake application up.
  
 
+
== Scenario ==
Scenario:
+
# After logging-in  to BM a terminal application sends message REWIND_TYPE_TERMINAL_ATTACH with data of TokenService URL and device token
# Terminal sends to BM a messasge REWIND_TYPE_TERMINAL_IDLE that contains string in then next format: FCM-HTTP-v1 <URL of token service> <device token>
+
# When terminal application needs to go background or exit it sends to BM a messasge REWIND_TYPE_TERMINAL_IDLE to switch connection to stand-by mode
# BM checks local database for suitable access token and application ID *'''A1'''
+
# When BM needs to send something to a terminal application it checks local database for suitable access token and application ID *'''A1'''
# BM sends push message to terminal using suitable access token and application ID
+
# BM sends push message to terminal application using suitable access token and project ID
 +
# Terminal application receives push message from FCM
 +
# Terminal application goes online and reconnects to BM using message REWIND_TYPE_KEEP_ALIVE
  
 
'''A1'''. Token information not found:
 
'''A1'''. Token information not found:
 
# BM queries <URL of token service> for application and token info
 
# BM queries <URL of token service> for application and token info
# Token Service does authentication at Google OAuth 2,0 service using its private keys
+
# Token Service does authentication at Google OAuth 2.0 service using its private key
# Token Service passes pplication-id, access-token and expiration-time to BM
+
# Token Service passes application-id, access-token and expiration-time to BM
# BM stores token access token and application ID in database
+
# BM stores access token and application ID in its database
 +
 
 +
[[File:BM-FCM.png|600px]]
 +
 
 +
== Security ==
 +
* Terminal may add a verification string to URL of token service to check that request of token initiated by vendor's application, it could be something like CRC32 hash of BM's IP salted with secret known only to terminal and token service.
 +
* BM will call token service only in following cases:
 +
** token not found
 +
** token expired
 +
** FCM returned code 401
 +
 
 +
== Examples ==
 +
 
 +
=== Terminal requests BM to register push-channel ===
 +
'''Please check main article for actual binary format!'''<br/>
 +
<code>
 +
[REWIND_TYPE_TERMINAL_ATTACH] http://my-dmr-vendor.com/token/?code=123456 jhsdfjasdfsdfeTERTcxvvxerSR
 +
</code>
 +
 
 +
Where
 +
* ''http://my-dmr-vendor.com/token/?code=123456'' is address of TokenService to provide OAuth 2.0 token for FCM authentication,
 +
* ''jhsdfjasdfsdfeTERTcxvvxerSR'' is a device token to deliver messages to
 +
 
 +
=== BM requests Token Service ===
 +
<code>
 +
GET http://my-dmr-vendor.com/token/?code=123456
 +
</code>
 +
 
 +
=== Token Service responds to BM ===
 +
<syntaxhighlight lang="JavaScript">
 +
{
 +
  type: 'FCM HTTP v1',
 +
  project: 'mydmrapp-jaso42',
 +
  token: 'isdmlifdlWERWdsfWsdfsfsdfWER',
 +
  expires: 3600
 +
}
 +
</syntaxhighlight>
 +
 
 +
 
 +
Where:
 +
* ''mydmrapp-jaso42'' - Google's project ID for application
 +
* ''isdmlifdlWERWdsfWsdfsfsdfWER'' - FCM OAuth 2.0 token
 +
 
 +
=== BM sends Push to an application ===
 +
<syntaxhighlight lang="JavaScript">
 +
{
 +
  "message":
 +
  {
 +
    "token" : "jhsdfjasdfsdfeTERTcxvvxerSR",
 +
    "data" :
 +
    {
 +
      "type" : "data"
 +
      "body" : "<base64-encoded REWIND datagram>"
 +
    },
 +
    "android":
 +
    {
 +
      "priority": "high",
 +
      "ttl": "0"
 +
    }
 +
  }
 +
}
 +
</syntaxhighlight>
 +
 
 +
== Links ==
  
Open questions:
+
* [https://firebase.google.com/docs/cloud-messaging/server Google Firebase Cloud Messaging Documentation]
* Should vendor's token service do validation of BM?
+
* [https://firebase.google.com/docs/reference/fcm/rest/v1/projects.messages Google Firebase Cloud Message Format]
 +
* [https://github.com/BrandMeister/TokenService Reference implementation of TokenService]

Latest revision as of 12:36, 8 February 2019

DRAFT

Conditions

  • Since publishing "FCM HTTP v1" Google improved security system of their FCM services. Now it requires to use short-time access tokens of OAuth 2.0 service, which uses private key based authentication and specific Google software libraries.
  • Each terminal vendor has it's own application with it's unique Application ID registered and Google Firebase. Terminal may have several applications with different IDs. It should not be a good idea to hardcode Application IDs inside BM's code as well as vendor's private key to pass Google Authentication.
  • Due to real-time nature of the service all messages should be sent by BM directly. This should solve issues of inaccessability of service and power of vendor's site.

Assumptions

  • When terminal goes to the idle mode it may pass IDLE message to BM contains info about Vendor's service which will provide information to pass messages to FCM such as application identifiers, access token and expiration time.
  • On this way terminal vendor delegates message sending feature to BM without disclosing information of its private key.
  • BM / Registry will store these data and assosiate it with particular terminal / connection context and use it to wake application up.

Scenario

  1. After logging-in to BM a terminal application sends message REWIND_TYPE_TERMINAL_ATTACH with data of TokenService URL and device token
  2. When terminal application needs to go background or exit it sends to BM a messasge REWIND_TYPE_TERMINAL_IDLE to switch connection to stand-by mode
  3. When BM needs to send something to a terminal application it checks local database for suitable access token and application ID *A1
  4. BM sends push message to terminal application using suitable access token and project ID
  5. Terminal application receives push message from FCM
  6. Terminal application goes online and reconnects to BM using message REWIND_TYPE_KEEP_ALIVE

A1. Token information not found:

  1. BM queries <URL of token service> for application and token info
  2. Token Service does authentication at Google OAuth 2.0 service using its private key
  3. Token Service passes application-id, access-token and expiration-time to BM
  4. BM stores access token and application ID in its database

BM-FCM.png

Security

  • Terminal may add a verification string to URL of token service to check that request of token initiated by vendor's application, it could be something like CRC32 hash of BM's IP salted with secret known only to terminal and token service.
  • BM will call token service only in following cases:
    • token not found
    • token expired
    • FCM returned code 401

Examples

Terminal requests BM to register push-channel

Please check main article for actual binary format!
[REWIND_TYPE_TERMINAL_ATTACH] http://my-dmr-vendor.com/token/?code=123456 jhsdfjasdfsdfeTERTcxvvxerSR

Where

BM requests Token Service

GET http://my-dmr-vendor.com/token/?code=123456

Token Service responds to BM

{
  type: 'FCM HTTP v1',
  project: 'mydmrapp-jaso42',
  token: 'isdmlifdlWERWdsfWsdfsfsdfWER',
  expires: 3600
}


Where:

  • mydmrapp-jaso42 - Google's project ID for application
  • isdmlifdlWERWdsfWsdfsfsdfWER - FCM OAuth 2.0 token

BM sends Push to an application

{
  "message":
  {
    "token" : "jhsdfjasdfsdfeTERTcxvvxerSR",
    "data" :
    {
      "type" : "data"
      "body" : "<base64-encoded REWIND datagram>"
    },
    "android":
    {
      "priority": "high",
      "ttl": "0"
    }
  }
}

Links

DRAFT[edit]

Conditions:


Assumptions:


Scenario:

  1. Terminal sends to BM a messasge REWIND_TYPE_TERMINAL_IDLE that contains string in then next format: FCM-HTTP-v1 <URL of token service> <device token>
  2. BM checks local database for suitable access token and application ID *A1
  3. BM sends push message to terminal using suitable access token and application ID

A1. Token information not found:

  1. BM queries <URL of token service> for application and token info
  2. Token Service does authentication at Google OAuth 2,0 service using its private keys
  3. Token Service passes pplication-id, access-token and expiration-time to BM
  4. BM stores token access token and application ID in database

Open questions: