In the first post of this blog series about the OAuth2, I provided a comprehensive overview of the OAuth2 core specification and its supporting specification. In the 2nd post, I discussed the OAuth2 Authorization Server Metadata specification. In this post, I will discuss the OAuth2 Dynamic Client Registration (DCR) and the OAuth2 Dynamic Client Registration Management (DCR-M) protocols that play and vital role in the practical use of OAuth2.
Having a basic understanding of the Authorization Code grant type is a prerequisite for this current post, and you refer to my OAuth2 overview post from here.
This article is the second post in my blog series about the OAuth2; reading the first post may help you to understand this current topic easily.
Although I intended to provide an overview above the OAuth2 and related specifications, I have extensively discussed the Authorization Code grant type in the previous post. The Authorization Code grant type consists of two distinct steps:
Now it has been nearly 8 years after the formal approval of OAuth2 Core standard by IETF. Obviously, the OAuth2 is not a new technology for writing yet another introduction post, especially in 2020. So what has motivated me to write an introductory post about OAuth2 at this point? I believe it’s worth discussing that first.
OWASP project recently finalised their API Security Top 10 list into RC level; you can have a look at it from here. When I went through the list, I was a bit surprised because most of the top security vulnerabilities are fundamental principles that we had been practising for a long time; it seems that we have forgotten most of these basics while we are busy with new technology advancements.
This post discusses Broken Object Level Authorization and Broken Function Level Authorization vulnerabilities and several remedies to avoid these vulnerabilities. …
So far I have discussed key constructs of SAML 2.0 core standard and few supportive standards such as IDP Discovery and SAML Metadata too. Starting from this post, I’m planning to discuss SAML Profiles, if I recall our discussion about SAML profiles, profiles are practical use-cases defined in terms of basic SAML constructs such as Assertions, Bindings and Protocols. In this post, I will discuss ‘Web Browser SSO Profile’, which is one of the widely used SAML profile. In Web Browser SSO profile, a user access a SP via a web browser, the presence of a web browser is mandatory.
This post is somewhat different from other posts of this series, majority of the concepts that we are discussing here are not only specific to SAML, those can be used with some other protocols as well, additionally, some of the real-world examples used here to describe some general concepts are not related to SAML as well but I used them because they are the best suite to illustrate those concepts.
As the tradition we used throughout this series, let’s try to understand why we need IdP discovery in the first place. …
WSO2 Identity Server (WSO2 IS) is a leading open source IAM (Identity and Access Management ) product and a member of WSO2 middleware platform. Like any other WSO2 product WSO2 IS is also licensed with Apache 2.0 which grants true freedom for users, in other words as far as you can manage yourself you don’t need to purchase any special licenses from us to run WSO2 IS for any production use.
As we previously discussed, SAML is a structured format to define security information (assertions) about a subject (usually about an individual) by an authorized authority called asserting party; however, there is no point to generate a SAML assertion and keep it itself by the asserting party, instead generated SAML assertions need to be shared with another party so that this other party can use this SAML assertion, technically we call this other party as relying party.
During the last post, I discussed some of the practical use cases of SAML, within this post I will try to discuss a few basic concepts related to SAML.
Generally, we refer SAML as a one stranded but it has been evolved into a complex ecosystem with a number of technical specifications, however in the current post I limit to discuss some core specifications, we mainly focus on SAML Core ( Assertions and Protocols ) and SAML Bindings.
Following diagram illustrate the relationship among these specifications.
SAML technical overview document use following diagram to illustrate associations between the above specifications.
Recently I have been working closely and directly on Identity and Access Management (IAM) domain, which also raised a necessity to revisit most of the IAM concepts and standards again. As a person with a limited memory capacity I used to blog my studies/readings as much as possible, here is another attempt, this time on SAML.
Without any doubt I would say, SAML has been used by the vast majority of Internet users, it’s a different question whether they are aware that they have been using SAML or not.
Well, if I start with old school type question …