NodeJS Logging integration with Azure Log Analytics/Sentinel

If you want to send data from NodeJS application to Log Analytics/Sentinel you can do it by using the HTTP Log Collector API.

Sending data to Sentinel Connected Log Analytics WorkSpace as part of incoming request callback

Note: If your app is in Azure PaaS solution, you should check out AppInsights first before going to this route 🙂

Writing module for the Log Collector API

There we’re some existing examples to do this, but I couldn’t get them to work in quick breeze. Due to this I did my own implementation with some key differences:

Signature generation part is done in two phases to improve readability

  • Basically I separated the creation of buffer shared key to base64 into an separate variable (var)

Function is bit different with callbacks and try catch logic added

Request Module will handle the Body Payload as non stringified

I did find, that If I sent the body payload stringified, it wouldnt match with the signature. To get the signature to match with the body payload, I added the request option json:true, and sent the non-stringified JSON payload.

The module to be imported

//https://nodejs.org/api/crypto.html
//https://docs.microsoft.com/en-us/azure/azure-monitor/platform/data-collector-api
//https://stackoverflow.com/questions/44532530/encoding-encrypting-the-azure-log-analytics-authorization-header-in-node-js
const rq = require('request')
const crypto = require('crypto')
const util = require('util')
function PushToAzureLogs (content,{id,key,rfc1123date,LogType}, callback) {
    console.log(id)
    try {
        //Checking if the data can be parsed as JSON
        if ( JSON.parse(JSON.stringify(content)) ) {
            var length = Buffer.byteLength(JSON.stringify(content),'utf8')
            var binaryKey = Buffer.from(key,'base64')
            var stringToSign = 'POST\n' + length + '\napplication/json\nx-ms-date:' + rfc1123date + '\n/api/logs';
            //console.log(stringToSign)
    
            var hash = crypto.createHmac('sha256',binaryKey)
            .update(stringToSign,'utf8')
            .digest('base64')
            var authorization = "SharedKey "+id +":"+hash
            var options= {
            json:true,
            headers:{
            "content-type": "application/json", 
            "authorization":authorization,
            "Log-Type":LogType,
            "x-ms-date":rfc1123date,
            "time-generated-field":"DateValue"
            },
            body:content    
            }
            var uri = "https://"+ id + ".ods.opinsights.azure.com/api/logs?api-version=2016-04-01"
    
            rq.post(uri,options,(err,Response) => {
                //return if error inside try catch block 
                if (err) {
                    return callback(("Not data sent to LA: " + err))
                }
               callback(("Data sent to LA " +util.inspect(content) + "with status code " + Response.statusCode))
    
            })
    
        }
        //Catch error if data cant be parsed as JSON
    } catch (err) {
        callback(("Not data sent to LA: " + err))
    }
           
}
module.exports={PushToAzureLogs}

Example from ExpressJS

//Add your other dependencies before this
const logs = require('./SRC/laws')
//define workspace details
const laws = {
    id:'yourID',
  key:'yourKey',
    rfc1123date:(new Date).toUTCString(),
    LogType:'yourLogType'
}
app.get('/graph', (request,response) => {
//not related to LA, this the data I am sending to LA
    var token = mods.readToken('rt').access_token
    mods.apiCall(token,'https://graph.microsoft.com/v1.0/me?$select=displayName,givenName,onPremisesSamAccountName', (data) => {
    console.log('reading graph', data)
//LA object
    jsonObject = {
        WAFCaller:request.hostname,
        identity:data.displayName,
        datasource:request.ip
    }
    console.log(jsonObject)
//send data to LA
        logs.PushToAzureLogs(jsonObject,laws,(data)=> {
            console.log(data)
        })
//return original response
    response.send(data)
    })
})

Once the data is sent, it will take about 5-10 minutes, for the first entries to be popping up

If /when you attach the Log Analytics workspace to Sentinel, you can then use it create your own hunting queries, and combine the data you have with TI-feeds etc

Happy hunting!

Azure AD – Add Custom claims for WS-Federation applications

Disclaimer: The information in this weblog is provided “AS IS” with no warranties and confers no rights.

Most guides using Azure AD as IDP focus at OAuth and OAuth2/w OIDC flows for API access, and for enterprise SSO SAML. Not much endorsement for WS-Federation, and that’s understandable because the two previous options cover pretty much every scenario you would ideally have. But what if you have a app that is using explicitly WS-Federation? For example Microsoft OWIN based application?

There aren’t good support articles on using WS-Federation and custom claims in Azure AD when Azure AD is IDP, but WS-Federation is definitely supported when Azure AD is acting as IDP .

The only article I found covering custom claims and mentioning WS-Federation was the one I’ve used to write my previous article on preview of custom claims (how to get sAMAccountName into JWT tokens)

Since Azure AD App’s are largely protocol agnostic I figured that maybe the claims mappings are somewhat ambiguous also, just as long you understand how custom claims, and federations work

Guide to testing

The order here is important. While SAML endpoint is enabled by default in any Azure AD App, any specific settings, especially one’s for configuring Service Provider aren’t directly available in the ”non-SAML” app you create – Unless you play around with the App Registration Manifest. But there are other features that require spawning app initially as SAML app (For example using custom token sign-in cert, using token encryption and so on)

  • Configure new SAML federation at Azure AD
  • Add the custom claims for the federation
  • Set Single-Sign On mode to disabled
    • If you’re planning to use this in production, you have get the Metadata from SAML federation settings, I will do some further investigation later to update this blog
  • For metadata replace the metadata URL with tenant and AppID details

Test the federation.

I have handy NodeJS Express App I use pretty much for testing and debugging any authorization related stuff, with very simple purpose of catching different inbound calls.

About the code… The code itself is epitome of laziness, so I am too embarrassed to share it :)…

  • Invoke the call
    • Use AppID or any Identifier you’ve defined in the manifest
    • If you have multiple reply URL’s define the ’wreply’ param
https://login.microsoftonline.com/common/wsfed?
 wtrealm=1de8c976-fe00-4008-91d5-e5a2381d40a6
 &wctx=WSfedState
 &wa=wsignin1.0
  • Confirm the emitted claims
    • In this particular case its user.displayname +(join) user.dnsdomain
Typical WS-Federation body

There are many questions and details that I could add here, but since I am just fooling around with a feature, I am not devoting any more time until there is actual production need for such scenario.