A while back I had the incredible fortune to collaborate with Inbal Silis and Bojan Magusic on this blog post, summarizing the learnings we saw with customers that used Microsoft Defender for Cloud to improve the Security Posture of their workloads in different Clouds.
The purpose of this article is to provide organizations with a comprehensive understanding of all the agents and resources deployed as part of Defender for Server, Defender for Container, Defender for SQL in their AWS/GCP environment by Defender for Cloud. The article aims to guide organizations on the impact of Defender for Cloud on their environment and what they need to remove when switching Defender for Cloud plans on the security connector. Where possible this article should avoid duplicating information that is already available on Microsoft Learn and focus on providing information that is not publicly available or documented on Microsoft Learn.
I started blogging again, but this time the article is on the Microsoft Tech Community platform. I’ve been working with Microsoft Sentinel for 3 years now, from its start as Azure Sentinel. The contents of this blog are the result of my experience delivering migrations to Sentinel from other SIEMs and green-field adoption projects where SOC teams learn and adopt Microsoft Sentinel as their SIEM. On several of these projects the three main ways of ingesting Windows Server OS logs for IaaS architectures is a recurring theme. Even in multi-cloud environments. This article outline the main 3 ways to ingest OS events, which ones are considered Security Events, and the gotchas when utilizing a Windows Event Collector.
If you work with the Azure Cloud as I do, keeping up with the service releases or looking at an overview of each service can be challenging. The Azure Periodic Table helps keeping up with these challenges.
A lot of us have been waiting for OWASP to publish a new set of top 10. Now that APIs are key in every solution, OWASP published the Top 10 Most Critical API Security Risks! It is worth the time to read it through. You don’t want to be in the news for the wrong reasons. #infosecurity#applicationsecurity
Yesterday I was wondering if Microsoft support middleware packages for Java to allow the typical resource provider actions in an access_token or id_tokens, similarly to what the OWIN NuGet packages do or the PassportJS libraries for NodeJS. These last two libraries act as middlewares intercepting the HTTP requests. They allow to, programmatically, parse the Authorization headers to extract Bearer tokens, validate the tokens, extract claims from the tokens etc, etc.
The libraries I had found so far, and that I was familiar with, were the MSAL set of libaries and the ADAL set of libraries. These are client side libraries, meant for applications acting or APIs acting as OAuth2 Clients (not as Resource Providers)
Spring Boot is a wrapper of Spring Framework libraries packaged with preconfigured components.
They can also work with AAD and Spring Security, but there aren’t many articles out there related to that framework and how to use it when AAD is the IdP providing JWT tokens except for this one:
There is also this old blog post with some sample code(using spring framework security, however the example is for illustration purposes only, and uses an access_token issued for a SPA client application in order to request access to an API, which is not exaclty the case of the application we’re trying to modernize (multi-page JSP web application)
Microsoft identity providers work with two types of libraries:
Client libraries: Native clients (iOS, Android), JavaScript SPA applications, and servers use client libraries to acquire access tokens for calling a resource such as Microsoft Graph or other APIs.
Server middleware libraries: Web apps use server middleware libraries for user sign-in. Web APIs use server middleware libraries to validate tokens that are sent by native clients or by other servers.
Microsoft developers produce and maintains two client Open Source libraries for Java that work with Microsoft identity providers => ADAL and MSAL
They support the industry standards OAuth2.0 and OpenID
Connect 1.0
There is also an oauth2-oidc-sdk for Java that contain the namespaces needed for token deserialization, token validation(s) and processing of claims, which is typically done server side, when the web app or api receives a bearer token in the HTTP(S) Security Authorization Header.
To my knowledge, this SDK is not maintained by Microsoft.
Note: Server side validation of the token, specifically, the decryption of the token digital signature and the comparison of the decrypted hash vs. the calculated hash is critical to ensure the token claims weren’t tampered in transit and that the IdP wasn’t spoofed. There are other token validations, but this one in particular guarantees the integrity of the information and the source of the token.
Azure AD B2C is one of the most fast growing Identity Providers in the world. When this type of tenant was created for social identities and digital citizens, the Microsoft Identity team didn’t anticipate its massive growth. Over 1 billion of users authenticate to their apps, and apps to apis, using this type of Azure directory or tenant. When privacy norms such as GDPR in the European Union and CCPA in California, USA, came about, the flexibility provided by custom policies; the white label customization of the html/css and the Identity Experience Framework, allowed solutions where the end users have more control of their data, including the ability to remove the personal data that applications collect from them (profile information, credentials, user attributes and permissions). Microsoft Graph also provides one of the first RESTful APIs that allow application developers to programatically perform CRUD operations on user accounts and principals associated to applications and services.
This month the Microsoft Identity team has published a number of public articles to guide developers on the automation steps with Azure AD B2C:
A colleague of mine that also specializes on Identity Management (IdM) with Identity Providers (IdP) such as AAD, Okta, ADFS, Ping Federate and IdentityServer, published this summary on the 6 different flows encompassed by the OAuth2.0 RFCs.
If you work with the OAuth 2.0 Authorization Framework and the OIDC Authentication Framework, you’ll find the article below very interesting.
One thing to remember when you study the Authorization Grants or Flows in OAuth2.0 is that neither the Extension Grant flow nor the Client Credentials flow require the end user to interact with a browser.
The Client Credentials Flow is designed for headless daemons/services where the is no human interaction. The Extension Grant Flow is sometimes named as OBO (on-Behalf-of) and can be used to exchange SAML2.0 tokens for OAuth2.0 access tokens/bearer tokens. This grant (Extension Grant) doesn’t necessarily require user interaction during the token exchange at the IdP for an authorized application if the token being exchanged is still valid. (OAuth2.0 Extension Grant) In this case the SAML2.0 bearer token with its assertions is exchanged for an access token/bearer token/JWT that represents the client application or service.
