oAuth , OpenID, OpenID Connect, SAML

oAuth : Open Authorization  Framework 
It allows you to delegate access/authorization  to third parties without sharing credentials. Third parties can access the resources on your behalf. 

oAuth framework evolved over time.  First oAuth 1.0 came up. It used HTTP ( not HTTPS )  but encrypted the sensitive information at the endpoints.  This made the implementation bit difficult and cumbersome. 

oAuth 2.0  is very different than 1.0 and it addressed some of the challenges of 1.0/1.1.  It removed the need for encryption at the endpoints but it requires HTTPS, which is widely available.  It made the implementation faster and easier. It also came up with multiple flows ( auth code, implicit, resource owner credential, client credential, refresh token )  for different scenarios. 

Here is link to oAuth 2.0 flows

OpenID is open standard for authentication , promoted by OpenID foundation.  It allows replying parties ( RP) like web site to authenticated by third party, OpenID Providers (OP or IDP). OpenID defines framework for communication that must take place between RPs and IDPs. OpenID does not mandate how IPD authenticates user. OpenID refers to the identifier in the standard,  which takes the form of an URI and is managed by IDP.

OpenID Connect: It is an identity layer on top of oAuth 2.0.  It adds mechanism to authenticate by adding openid scope in authorization request. The information is returned back in JWT called ID token.  It also specifies the use of claims for getting basic profile information about end user (UserInfo endpoint) .  If RP and OP don't have an existing relationship,  OpenID Connect also specifies framework to discover Openid Providers  and register the RPs dynamically.

SAML( Security Assertion Markup Language ) : is protocol for exchanging authentication, authorization and limited profile information about the principal between identity provider and  service provider. SAML came into existence to standardize single sign on (SSO) across multiple security domains.  SSO across multiple domains was needed and everyone was coming up with their own proprietary implementation which was not interoperable. This gave birth to SAML. SAML has evolved over time. The main versions are 1.0, 1.1 and 2.0.   1.0 and 1.1 are quite similar with minor differences but 2.0 is quite different and not compatible with 1.x. SAML 2.0 is convergence of Liberty ID-FF and contributions from Shibboleth. Concept of "circle of trust" came from Liberty. In SAML 2.0 , this is achieved by sharing/publishing  metadata for IDP/SP. 

Some of  differences between SAML 2.0 and 1.1 include following:
  • Differences in on-the -wire representation of assertions and messages
  • Different way of organizing the specs
  • Provision for encryption was introduced in 2.0
  • Single logout protocol was introduced in 2.0
  • Clear separation between bindings and profiles in 2.0
See section 6  for this link for more details. 

SAMPL Profile: It describes in details how assertions, protocol and bindings come together to support a use case. Most important profile is "Web Browser SSO". 

SAML Binding : Mapping of SAML protocol messages onto standard messaging formats or communication protocols. For example "SAML SOAP Binding"

oAuth, OpenID, OpenID Connect
  • oAuth :    access token ( authorization to access certain  resources , but no user info )
  • OpenID : access token + id_tokens ( authorization to access certain  resources+ user_id  but no additional info about user )
  • OpenID Connect: access token + id_tokens and userinfo endpoint for additional user profile information based on authorization from user





Comments

Post a Comment

Popular posts from this blog

SQL

Joins - Not always very obvious ( Following example uses Hive ). create table x_temp ( name string, p_date int  ) insert into x_temp(name,p_date) values ('x1',20181025),('x2', 20181026), ('x3',20181027) create table y_temp ( name string, s_date int  ) insert into y_temp(name,s_date) values ('x1',20181025),('x2', 20181026), ('x3',20181027) create table z_temp ( name string, p_date int, s_date int ) insert into z_temp(name,p_date,s_date) values ('z1','20181025','20181025') select x.*, y.* from x_temp x, y_temp y, z_temp z  where x.p_date != z.p_date and  y.s_date != z.s_date) generates 4 records... x.name,x.p_date,y.name,y.s_date x2, 20181026, x2, 20181026 x3, 20181027, x2, 20181026 x2, 20181026, x3, 20181027 x3, 20181027, x3, 20181027 select x.*, y.* from x_temp x, y_temp y, z_temp z  where x.p_date != z.p_date or  y.s_date != z.s_date) generates 8 records x.name,x.p_date,y.
Read more

Analytics

Types of Analytics ( Notes from AWS Course )  Descriptive - What happened ?  hindsight  Diagnostic - Why did it  happen?  hindsight & insight  Predictive  - What will happen ? insight & foresight  Prescriptive - What should I do ? foresight  Cognitive & AI  - What are recommended actions ? foresight & hypothesis input  Popular BI Tools:  https://www.cio.com/article/3284415/10-bi-tools-for-data-visualization.html
Read more

HIVE

1. When doing multi table joins, except the last ( right most ) table, other tables are buffered in the reducers. So to have less memory footprint on reducers, largest tables should be the last one as it is not buffered but streamed to reducers.   For Impala , it is different. 2.  You can filter the unwanted records within the join itself. SELECT  a.*,   b. * FROM a LEFT OUTER JOIN b ON ( a.key=b.key  AND  b.name= 'Tim'   AND a .name= 'Kim' ) 3. Joins are left associative. So execution happens from left to right and the result of joins is  fed into next join operation. 4. To find the value of variable     set hive.execution.engine 5. To find values of all variables set  6. If you want to pass different hive configuration settings in hive shell, you can use --hiveconf. For example hive --hiveconf hivi.optimize.sort.dynamic.partition=true --hiveconf hive.exec.dynamic.partition.mode=nonstrict 7.  In case you accidentally drop the p
Read more