Version 6

    What is a Signed Fetch

    Signed fetch is a way for your Jive App / Tile to connect to remote services with the actor's identity embedded in the request that can be validated.  Your remote service can then use this information to trust the request and allow for a seamless experience, if desired.

     

    Example Signed Fetch

    The following is an example of a request that comes from a Jive App when the request is “Signed”, this can be from:

    osapi.http.get( { 
        'href': xxxx, 
        'headers' : {  'Content-Type': ['application/json'] },
        'noCache': true, 
        'authz': 'signed' }
    ).execute(function (response) { .... }
       

    or even a simple app view definition in your app.xml:

     

      <Content type="html" view="xxxxxxxx" href="xxxxxxxx.html" preferred_height="570" preferred_width="840" 
               authz="signed" />

     

    Headers

    Host:  xxxxxxxxxxxxxxxxxxxxx

    X-Shindig-AuthType: signed

    Authorization: JiveEXTN algorithm=HmacSHA256&client_id=xxxxxx&jive_url=https%3A%2F%2Fxxxxxxxxxx.com&tenant_id=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxx&timestamp=xxxxxxxxxxxxx&signature=xxxxxxxxxxxxxxxxxxxxxxxxxxx

    X-Jive-Apps-Market-ID: 07d04c88-dc80-4655-adef-b18e2f2eaa12

    X-Jive-User-Email: user@somedomain.com

    X-Jive-User-External: false

    X-Jive-User-ID: 1234

    X-shindig-dos: on

      

     

    Verify the Request

    Your first step is to validate that the request is real.  That is to say, Did it come from a real Jive server?  To validate it you do the following:

    • Confirm that the X-Shindig-AuthType header is  "signed" ... this will let you know that your request needs to be validated.
      • (or do a Authorization header begins with JiveEXTN as a short-cut)
    • Check the Authorization Header and make sure that it begins with JiveEXTN.  If so, then this document applies.
      • If not, then then your request may be coming from a legacy AppsMarket App, and you will need to look at the following document to verify the request.
    • Substring the value to the Authorization header to begin after the "JiveEXTN " (i.e. the first character in this example, would be the "a" in algorithm) and last character would be the last parameter before the signature parameter (in this case, the last "x" in timestamp variable)
    • Take this substring value, and Base64 decode it.
    • Using the algorithm value to influence how you generate a new signature on your end.  If the signature you create matches the one sent, then you know you can trust it.

     

    Example Implementations

    The following is a table of links of implementations in various languages you can use in real world applications, or as a starting point if you wish.

     

                                                

     

    Identify the User

    You'll notice that in the headers, there are a series of X-Jive-User-* headers.  Use these values to identify the user in your remote system.

    • X-Jive-User-External - If true, then you should be able to look the user's identity up via the X-Jive-User-Email value in your shared IDP.

     

    Putting It All Together

    At this point, you should have all the information you need about the origination.

    • jive_url - Home URL for the Jive instance where the app is installed.
    • tenant_id - a unique ID to identify the Jive instance that never changes.
    • user's identity - a trusted identity for who is performing the action on the service.
    • context - Context can be passed in standard request parameters or body (i.e. url-encoded parameters or JSON body).

     

    At this point, it is up to your service to do its job. =)