Authentication & Authorization & Access Control - OAuth 2.0 & ABAC

  

Access Control

RBAC(role-based access control) to ABAC(Attribute-based access control)：
https://en.wikipedia.org/wiki/Attribute-based_access_control

引用

Historically, access control models have included mandatory access control (MAC), discretionary access control (DAC), and more recently role-based access control (RBAC). These access control models are user-centric and do not take into account additional parameters such as resource information, relationship between the user (the requesting entity) and the resource, and dynamic information e.g. time of the day or user IP. ABAC tries to address this by defining access control based on attributes which describe the requesting entity (the user), the targeted object or resource, the desired action (view, edit, delete...), and environmental or contextual information. This is why access control is said to be attribute-based.

http://www.webfarmr.eu/2010/09/xacml-101-a-quick-intro-to-attribute-based-access-control-with-xacml/
Key words of ABAC:

引用

Subject: user
Resource: course, attribute: privacy（private or public)
Action: CRUD
Policy:
Rule:

某种意义上，i可以将 RBAC 看成是 ABAC 的子集，since a role is just one attribute.

  OAuth 2.0

OAuth 2 Simplified
https://aaronparecki.com/2012/07/29/2/oauth2-simplified


The OAuth 2.0 Specification – http://tools.ietf.org/html/rfc6749

引用

OAuth defines four roles:

   resource owner
      An entity capable of granting access to a protected resource.
      When the resource owner is a person, it is referred to as an
      end-user.

   resource server
      The server hosting the protected resources, capable of accepting
      and responding to protected resource requests using access tokens.

   client
      An application making protected resource requests on behalf of the
      resource owner and with its authorization.  The term "client" does
      not imply any particular implementation characteristics (e.g.,
      whether the application executes on a server, a desktop, or other
      devices).

   authorization server
      The server issuing access tokens to the client after successfully
      authenticating the resource owner and obtaining authorization.

   The interaction between the authorization server and resource server
   is beyond the scope of this specification.  The authorization server
   may be the same server as the resource server or a separate entity.
   A single authorization server may issue access tokens accepted by
   multiple resource servers.

https://www.forgerock.com/blog/oauth2/

引用

In addition to these four roles, two different types of tokens are defined by the standard:

Access Token :
Access tokens are credentials provided by the client to access protected resources.  An access token is a string that represents an authorization issued to the client. Tokens represent specific scopes and durations of access, granted by the resource owner, and enforced by the resource server and authorization server. The access token provides an abstraction layer, replacing different authorization constructs such as traditional credentials (username/password) with a single token that is understood by the resource server.

Refresh Token :
Although not mandated by the specification, access tokens ideally have an expiration time that can last anywhere from a few minutes to several hours. Refresh tokens are credentials that are used to obtain access tokens. Refresh tokens are issued to the client by the authorization server and are used to obtain a new access token when the current access token becomes invalid or expires.

OpenID Connect:
Why Not Just Use OAuth 2.0?
http://stackoverflow.com/questions/33934920/what-openid-connect-adds-to-oauth-2-0-why-is-oauth-2-0-not-sufficient-for-authe
http://oauth.net/articles/authentication/
https://developer.salesforce.com/page/Inside_OpenID_Connect_on_Force.com#Why_Not_Just_Use_OAuth_2.0.3F


Control Flags of PAM (pluggable authentication module):
http://docs.oracle.com/javase/6/docs/api/javax/security/auth/login/Configuration.html

引用

The Flag value controls the overall behavior as authentication proceeds down the stack. The following represents a description of the valid values for Flag and their respective semantics:

      1) Required     - The LoginModule is required to succeed.
                        If it succeeds or fails, authentication still continues
                        to proceed down the LoginModule list.

      2) Requisite    - The LoginModule is required to succeed.
                        If it succeeds, authentication continues down the
                        LoginModule list.  If it fails,
                        control immediately returns to the application
                        (authentication does not proceed down the
                        LoginModule list).

      3) Sufficient   - The LoginModule is not required to
                        succeed.  If it does succeed, control immediately
                        returns to the application (authentication does not
                        proceed down the LoginModule list).
                        If it fails, authentication continues down the
                        LoginModule list.

      4) Optional     - The LoginModule is not required to
                        succeed.  If it succeeds or fails,
                        authentication still continues to proceed down the
                        LoginModule list.

The overall authentication succeeds only if all Required and Requisite LoginModules succeed. If a Sufficient LoginModule is configured and succeeds, then only the Required and Requisite LoginModules prior to that Sufficient LoginModule need to have succeeded for the overall authentication to succeed. If no Required or Requisite LoginModules are configured for an application, then at least one Sufficient or Optional LoginModule must succeed.