libre.sh/keycloak-scim
2
0
Fork 0
Code Issues 14 Pull requests Releases Packages Activity Actions 6

Update http://openid.net to https://openid.net

Browse source
This commit is contained in:
Johannes Knutsen 2018-09-06 00:10:36 +02:00 committed by Matthew Helmke
parent 2f09b8a810
commit 57bae71a75
11 changed files with 23 additions and 23 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

4
authorization_services/topics/service-authorization-obtaining-permission.adoc
View file

@ -23,8 +23,8 @@ permissions for the resource(s) and scope(s) being requested. This parameter all
* **claim_token_format**
+
This parameter is *optional. A string indicating the format of the token specified in the `claim_token` parameter. {project_name} supports two token
formats: `urn:ietf:params:oauth:token-type:jwt` and `http://openid.net/specs/openid-connect-core-1_0.html#IDToken`. The `urn:ietf:params:oauth:token-type:jwt` format
indicates that the `claim_token` parameter references an access token. The `http://openid.net/specs/openid-connect-core-1_0.html#IDToken` indicates that the
formats: `urn:ietf:params:oauth:token-type:jwt` and `https://openid.net/specs/openid-connect-core-1_0.html#IDToken`. The `urn:ietf:params:oauth:token-type:jwt` format
indicates that the `claim_token` parameter references an access token. The `https://openid.net/specs/openid-connect-core-1_0.html#IDToken` indicates that the
`claim_token` parameter references an OpenID Connect ID Token.
+
* **rpt**

4
securing_apps/topics/oidc/java/params_forwarding.adoc
View file

@ -2,7 +2,7 @@
==== Parameters Forwarding
The {project_name} initial authorization endpoint request has support for various parameters. Most of the parameters are described in
http://openid.net/specs/openid-connect-core-1_0.html#AuthorizationEndpoint[OIDC specification]. Some parameters are added automatically by the adapter based
https://openid.net/specs/openid-connect-core-1_0.html#AuthorizationEndpoint[OIDC specification]. Some parameters are added automatically by the adapter based
on the adapter configuration. However, there are also a few parameters that can be added on a per-invocation basis. When you open the secured application URI,
the particular parameter will be forwarded to the {project_name} authorization endpoint.
@ -37,7 +37,7 @@ from when the user authenticated. If user is authenticated longer than `maxAge`,
* kc_idp_hint - Used to tell {project_name} to skip showing login page and automatically redirect to specified identity provider instead.
More info in the link:{adminguide_link}#_client_suggested_idp[Identity Provider documentation].
Most of the parameters are described in the http://openid.net/specs/openid-connect-core-1_0.html#AuthorizationEndpoint[OIDC specification].
Most of the parameters are described in the https://openid.net/specs/openid-connect-core-1_0.html#AuthorizationEndpoint[OIDC specification].
The only exception is parameter `kc_idp_hint`, which is specific to {project_name} and contains the name of the identity provider to automatically use.
For more information see the `Identity Brokering` section in link:{adminguide_link}[{adminguide_name}].

6
securing_apps/topics/oidc/javascript-adapter.adoc
View file

@ -121,12 +121,12 @@ your application.
[[_javascript_implicit_flow]]
==== Implicit and Hybrid Flow
By default, the JavaScript adapter uses the http://openid.net/specs/openid-connect-core-1_0.html#CodeFlowAuth[Authorization Code] flow.
By default, the JavaScript adapter uses the https://openid.net/specs/openid-connect-core-1_0.html#CodeFlowAuth[Authorization Code] flow.
With this flow the {project_name} server returns an authorization code, not an authentication token, to the application. The JavaScript adapter exchanges
the `code` for an access token and a refresh token after the browser is redirected back to the application.
{project_name} also supports the http://openid.net/specs/openid-connect-core-1_0.html#ImplicitFlowAuth[Implicit] flow where an access token
{project_name} also supports the https://openid.net/specs/openid-connect-core-1_0.html#ImplicitFlowAuth[Implicit] flow where an access token
is sent immediately after successful authentication with {project_name}. This may have better performance than standard flow, as there is no additional
request to exchange the code for tokens, but it has implications when the access token expires.
@ -144,7 +144,7 @@ keycloak.init({ flow: 'implicit' })
One thing to note is that only an access token is provided and there is no refresh token. This means that once the access token has expired the application
has to do the redirect to the {project_name} again to obtain a new access token.
{project_name} also supports the http://openid.net/specs/openid-connect-core-1_0.html#HybridFlowAuth[Hybrid] flow.
{project_name} also supports the https://openid.net/specs/openid-connect-core-1_0.html#HybridFlowAuth[Hybrid] flow.
This requires the client to have both the `Standard Flow Enabled` and `Implicit Flow Enabled` flags enabled in the admin console.
The {project_name} server will then send both the code and tokens to your application.

12
securing_apps/topics/oidc/oidc-generic.adoc
View file

@ -1,6 +1,6 @@
=== Other OpenID Connect Libraries
{project_name} can be secured by supplied adapters that are usually easier to use and provide better integration with {project_name}. However, if an adapter is not available for your programming language, framework, or platform you might opt to use a generic OpenID Connect Resource Provider (RP) library instead. This chapter describes details specific to {project_name} and does not contain specific protocol details. For more information see the http://openid.net/connect/[OpenID Connect specifications] and https://tools.ietf.org/html/rfc6749[OAuth2 specification].
{project_name} can be secured by supplied adapters that are usually easier to use and provide better integration with {project_name}. However, if an adapter is not available for your programming language, framework, or platform you might opt to use a generic OpenID Connect Resource Provider (RP) library instead. This chapter describes details specific to {project_name} and does not contain specific protocol details. For more information see the https://openid.net/connect/[OpenID Connect specifications] and https://tools.ietf.org/html/rfc6749[OAuth2 specification].
==== Endpoints
@ -23,7 +23,7 @@ Some RP libraries retrieve all required endpoints from this endpoint, but for ot
The authorization endpoint performs authentication of the end-user. This is done by redirecting the user agent to this endpoint.
For more details see the http://openid.net/specs/openid-connect-core-1_0.html#AuthorizationEndpoint[Authorization Endpoint] section in the OpenID Connect specification.
For more details see the https://openid.net/specs/openid-connect-core-1_0.html#AuthorizationEndpoint[Authorization Endpoint] section in the OpenID Connect specification.
===== Token Endpoint
....
@ -33,7 +33,7 @@ For more details see the http://openid.net/specs/openid-connect-core-1_0.html#Au
The token endpoint is used to obtain tokens. Tokens can either be obtained by exchanging an authorization code or by supplying credentials directly depending on what flow is used.
The token endpoint is also used to obtain new access tokens when they expire.
For more details see the http://openid.net/specs/openid-connect-core-1_0.html#TokenEndpoint[Token Endpoint] section in the OpenID Connect specification.
For more details see the https://openid.net/specs/openid-connect-core-1_0.html#TokenEndpoint[Token Endpoint] section in the OpenID Connect specification.
===== Userinfo Endpoint
....
@ -42,7 +42,7 @@ For more details see the http://openid.net/specs/openid-connect-core-1_0.html#To
The userinfo endpoint returns standard claims about the authenticated user, and is protected by a bearer token.
For more details see the http://openid.net/specs/openid-connect-core-1_0.html#UserInfo[Userinfo Endpoint] section in the OpenID Connect specification.
For more details see the https://openid.net/specs/openid-connect-core-1_0.html#UserInfo[Userinfo Endpoint] section in the OpenID Connect specification.
===== Logout Endpoint
....
@ -105,7 +105,7 @@ credentials to obtain an Access Token, Refresh Token and ID Token from {project_
The flow is targeted towards web applications, but is also recommended for native applications, including mobile applications, where it is possible to embed
a user agent.
For more details refer to the http://openid.net/specs/openid-connect-core-1_0.html#CodeFlowAuth[Authorization Code Flow] in the OpenID Connect specification.
For more details refer to the https://openid.net/specs/openid-connect-core-1_0.html#CodeFlowAuth[Authorization Code Flow] in the OpenID Connect specification.
===== Implicit
@ -120,7 +120,7 @@ There's also a Hybrid flow where both the Access Token and an Authorization Code
One thing to note is that both the Implicit flow and Hybrid flow has potential security risks as the Access Token may be leaked through web server logs and
browser history. This is somewhat mitigated by using short expiration for Access Tokens.
For more details refer to the http://openid.net/specs/openid-connect-core-1_0.html#ImplicitFlowAuth[Implicit Flow] in the OpenID Connect specification.
For more details refer to the https://openid.net/specs/openid-connect-core-1_0.html#ImplicitFlowAuth[Implicit Flow] in the OpenID Connect specification.
[[_resource_owner_password_credentials_flow]]
===== Resource Owner Password Credentials

4
securing_apps/topics/overview/supported-protocols.adoc
View file

@ -4,7 +4,7 @@
==== OpenID Connect
link:http://openid.net/connect/[OpenID Connect] (OIDC) is an authentication protocol that is an extension of link:https://tools.ietf.org/html/rfc6749[OAuth 2.0].
link:https://openid.net/connect/[OpenID Connect] (OIDC) is an authentication protocol that is an extension of link:https://tools.ietf.org/html/rfc6749[OAuth 2.0].
While OAuth 2.0 is only a framework for building authorization protocols and is mainly incomplete, OIDC is a full-fledged authentication and authorization
protocol. OIDC also makes heavy use of the link:https://jwt.io[Json Web Token] (JWT) set of standards. These standards define an
identity token JSON format and ways to digitally sign and encrypt that data in a compact and web-friendly way.
@ -50,7 +50,7 @@ SAML tends to be a bit more verbose than OIDC.
Beyond verbosity of exchanged data, if you compare the specifications you'll find that OIDC was designed to work with the web while SAML was retrofitted to work on top of the web. For example, OIDC is also more suited for HTML5/JavaScript applications because it is
easier to implement on the client side than SAML. As tokens are in the JSON format,
they are easier to consume by JavaScript. You will also find several nice features that
make implementing security in your web applications easier. For example, check out the link:http://openid.net/specs/openid-connect-session-1_0.html#ChangeNotification[iframe trick] that the specification uses to easily determine if a user is still logged in or not.
make implementing security in your web applications easier. For example, check out the link:https://openid.net/specs/openid-connect-session-1_0.html#ChangeNotification[iframe trick] that the specification uses to easily determine if a user is still logged in or not.
SAML has its uses though. As you see the OIDC specifications evolve you see they implement more and more features that SAML has had for years. What we often see is that people pick SAML over OIDC because of the perception that it is more mature and also because they already have existing applications that are secured with it.

4
server_admin/topics/clients/client-scopes.adoc
View file

@ -31,10 +31,10 @@ list in the SAML assertion.
* For the OpenID Connect protocol, there are client scopes `profile`, `email`, `address`, `phone` and `offline_access` .
The client scope, `offline_access`, is useful when client wants to obtain offline tokens. Learn about offline tokens in the
<<_offline-access, Offline Access section>> or in the http://openid.net/specs/openid-connect-core-1_0.html#OfflineAccess[OpenID Connect specification],
<<_offline-access, Offline Access section>> or in the https://openid.net/specs/openid-connect-core-1_0.html#OfflineAccess[OpenID Connect specification],
where scope parameter is defined with the value `offline_access`.
The client scopes `profile`, `email`, `address` and `phone` are also defined in the http://openid.net/specs/openid-connect-core-1_0.html#ScopeClaims[OpenID Connect specification].
The client scopes `profile`, `email`, `address` and `phone` are also defined in the https://openid.net/specs/openid-connect-core-1_0.html#ScopeClaims[OpenID Connect specification].
These client scopes do not have any role scope mappings defined, but they have some protocol mappers defined, and these mappers correspond
to the claims defined in the OpenID Connect specification.

2
server_admin/topics/overview/how.adoc
View file

@ -2,7 +2,7 @@
=== How Does Security Work?
{project_name} is a separate server that you manage on your network. Applications are configured to point to and
be secured by this server. {project_name} uses open protocol standards like link:http://openid.net/connect/[OpenID Connect]
be secured by this server. {project_name} uses open protocol standards like link:https://openid.net/connect/[OpenID Connect]
or link:http://saml.xml.org/saml-specifications[SAML 2.0] to secure
your applications. Browser applications redirect a user's browser from the application to the {project_name} authentication
server where they enter their credentials. This is important because users are completely isolated from applications and

2
server_admin/topics/sessions/offline.adoc
View file

@ -2,7 +2,7 @@
=== Offline Access
Offline access is a feature described in http://openid.net/specs/openid-connect-core-1_0.html#OfflineAccess[OpenID Connect specification] .
Offline access is a feature described in https://openid.net/specs/openid-connect-core-1_0.html#OfflineAccess[OpenID Connect specification] .
The idea is that during login, your client application will request an Offline token instead of a classic Refresh token.
The application can save this offline token in a database or on disk and can use it later even if user is logged out.
This is useful if your application needs to do some "offline" actions on behalf of user even when the user is not online.

2
server_admin/topics/sso-protocols/oidc.adoc
View file

@ -2,7 +2,7 @@
=== OpenID Connect
link:http://openid.net/connect/[OpenID Connect] (OIDC) is an authentication protocol that is an extension of link:https://tools.ietf.org/html/rfc6749[OAuth 2.0].
link:https://openid.net/connect/[OpenID Connect] (OIDC) is an authentication protocol that is an extension of link:https://tools.ietf.org/html/rfc6749[OAuth 2.0].
While OAuth 2.0 is only a framework for building authorization protocols and is mainly incomplete, OIDC is a full-fledged authentication and authorization
protocol. OIDC also makes heavy use of the link:https://jwt.io[Json Web Token] (JWT) set of standards. These standards define an
identity token JSON format and ways to digitally sign and encrypt that data in a compact and web-friendly way.

2
server_admin/topics/sso-protocols/saml-vs-oidc.adoc
View file

@ -10,6 +10,6 @@ SAML tends to be a bit more verbose than OIDC.
Beyond verbosity of exchanged data, if you compare the specifications you'll find that OIDC was designed to work with the web while SAML was retrofitted to work on top of the web. For example, OIDC is also more suited for HTML5/JavaScript applications because it is
easier to implement on the client side than SAML. As tokens are in the JSON format,
they are easier to consume by JavaScript. You will also find several nice features that
make implementing security in your web applications easier. For example, check out the link:http://openid.net/specs/openid-connect-session-1_0.html#ChangeNotification[iframe trick] that the specification uses to easily determine if a user is still logged in or not.
make implementing security in your web applications easier. For example, check out the link:https://openid.net/specs/openid-connect-session-1_0.html#ChangeNotification[iframe trick] that the specification uses to easily determine if a user is still logged in or not.
SAML has its uses though. As you see the OIDC specifications evolve you see they implement more and more features that SAML has had for years. What we often see is that people pick SAML over OIDC because of the perception that it is more mature and also because they already have existing applications that are secured with it.

4
server_development/topics/auth-spi.adoc
View file

@ -760,7 +760,7 @@ For more details about this flow see the `Identity Brokering` chapter in link:{a
[[_client_authentication]]
=== Authentication of clients
{project_name} actually supports pluggable authentication for http://openid.net/specs/openid-connect-core-1_0.html[OpenID Connect] client applications.
{project_name} actually supports pluggable authentication for https://openid.net/specs/openid-connect-core-1_0.html[OpenID Connect] client applications.
Authentication of client (application) is used under the hood by the {project_name} adapter during sending any backchannel requests
to the {project_name} server (like the request for exchange code to access token after successful authentication or request to refresh token).
But the client authentication can be also used directly by you during `Direct Access grants` (represented by OAuth2 `Resource Owner Password Credentials Flow`)
@ -773,7 +773,7 @@ For more details about {project_name} adapter and OAuth2 flows see link:{adapter
Actually Keycloak has 2 builtin implementations of client authentication:
Traditional authentication with client_id and client_secret::
This is default mechanism mentioned in the http://openid.net/specs/openid-connect-core-1_0.html[OpenID Connect] or https://tools.ietf.org/html/rfc6749[OAuth2] specification and Keycloak supports it since it's early days.
This is default mechanism mentioned in the https://openid.net/specs/openid-connect-core-1_0.html[OpenID Connect] or https://tools.ietf.org/html/rfc6749[OAuth2] specification and Keycloak supports it since it's early days.
The public client needs to include `client_id` parameter with it's ID in the POST request (so it's defacto not authenticated) and the confidential client needs to include `Authorization: Basic` header with the clientId and clientSecret used as username and password.
Authentication with signed JWT::