Authentication & Authorization & Access Control - OAuth 2.0 & ABAC

[align=center][size=x-large][b] Access Control [/b][/size][/align]
RBAC(role-based access control) to ABAC(Attribute-based access control)：
[url]https://en.wikipedia.org/wiki/Attribute-based_access_control[/url][quote]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.[/quote]
[url]http://www.webfarmr.eu/2010/09/xacml-101-a-quick-intro-to-attribute-based-access-control-with-xacml/[/url]
Key words of ABAC:[quote]Subject: user
Resource: course, attribute: privacy（private or public)
Action: CRUD
Policy:
Rule:[/quote]某种意义上，i可以将 RBAC 看成是 ABAC 的子集，since a role is just one attribute.


[align=center][size=x-large][b] OAuth 2.0 [/b][/size][/align]


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


[b]The OAuth 2.0 Specification[/b] – [url]http://tools.ietf.org/html/rfc6749[/url][quote]OAuth defines four roles:

[b]resource owner[/b]
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.

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

[b]client[/b]
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).

[b]authorization server[/b]
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.[/quote]

[url]https://www.forgerock.com/blog/oauth2/[/url][quote][u][i]In addition to these four roles, two different types of tokens are defined by the standard:[/i][/u]

[b]Access Token :[/b]
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.

[b]Refresh Token :[/b]
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.[/quote]


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


Control Flags of PAM (pluggable authentication module):
[url]http://docs.oracle.com/javase/6/docs/api/javax/security/auth/login/Configuration.html[/url][quote]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.[/quote]