This page (revision-1) was last changed on 29-Nov-2024 16:16 by UnknownAuthor

Only authorized users are allowed to rename pages.

Only authorized users are allowed to delete pages.

Page revision history

Version Date Modified Size Author Changes ... Change note

Page References

Incoming links Outgoing links
OpenIG
OpenIG

Version management

Difference between version and

At line 1 added 26 lines
!!! Overview
[ForgeRock] [{$pagename}] provides a simple standards-based approach to extend access to web applications and application programming interfaces (APIs).
A perfect complement to existing WAM systems or as a stand-alone gateway, OpenIG provides a flexible policy enforcement point to support your current environment while migrating toward a modern, standards-based platform.
Can optionally and would typically be coupled with [OpenAM]
!! [{$pagename}] as an [OAuth 2.0] [Resource Server]
The [OAuth 2.0] Authorization Framework describes a way of allowing a third-party application to access a user's resources without having the user's credentials. When resources are protected with [OAuth 2.0], users can use their credentials with an [OAuth 2.0]-compliant identity provider, such as [OpenAM], Facebook, Google and others to access the resources, rather than setting up an account with yet another third-party application.
When [{$pagename}] acts therefore as an OAuth 2.0 [Resource Server], the role is to validate [Access Tokens]. Typically the [Resource Server] validates an access token by submitting the token to a [Token Introspection Endpoint]. The [Token Introspection Endpoint] typically returns the [Access Token] and the [OAuth Scopes] associated with the token, potentially with other information. For example, OpenAM maps [OAuth Scopes] to user profile attribute values by default, and also allows custom scope handling plugins.
You maybe wondering [Why Access Tokens]?
!! [{$pagename}] as an [OAuth Client]
[OAuth Client] is the third-party application that needs access to a user's protected resources.
The client application therefore has the user (the OAuth 2.0 [Resource Owner]) delegate authorization by authenticating with an identity provider (the OAuth 2.0 [Authorization Server]) using an existing account, and then consenting to authorize access to protected resources (on an OAuth 2.0 resource server).
[{$pagename}] can act as an [OAuth Client] when you configure an OAuth2ClientFilter. The filter handles the process of allowing the user to select a provider, and redirecting the user through the authentication and authorization steps of an [OAuth 2.0] [Authorization Code Grant], which results in the [Authorization Server] returning an [Access Token] to the filter. At the outcome of a successful authorization grant, the filter injects the [Access Token] data into a configurable target field of the exchange so that subsequent filters and handlers have access to the access token. Subsequent requests can use the access token without re-authentication.
If the protected application is an [OAuth 2.0] [Resource Server], then [{$pagename}] can send the [Access Token] with the resource request.
!! More Information
There might be more information for this subject on one of the following:
[{ReferringPagesPlugin before='*' after='\n' }]
This page (revision-1) was last changed on 29-Nov-2024 16:16 by UnknownAuthorTop