exceptionfactory commented on code in PR #7842: URL: https://github.com/apache/nifi/pull/7842#discussion_r1360674260
########## nifi-registry/nifi-registry-core/nifi-registry-docs/src/main/asciidoc/administration-guide.adoc: ########## @@ -253,6 +253,63 @@ The `kerberos-identity-provider` has the following properties: See also <<kerberos_service>> to allow single sign-on access via client Kerberos tickets. +[[openid_connect]] +=== OpenID Connect + +OpenID Connect integration provides single sign-on using a specified Authorization Server. +The implementation supports the Authorization Code Grant Type as described in +link:https://www.rfc-editor.org/rfc/rfc6749#section-4.1[RFC 6749 Section 4.1^] and +link:https://openid.net/specs/openid-connect-core-1_0.html#CodeFlowSteps[OpenID Connect Core Section 3.1.1^]. + +After successful authentication with the Authorization Server, NiFi Registry generates an application Bearer Token with an +expiration based on the OAuth2 Access Token expiration. NiFi Registry stores authorized tokens using the local State +Provider and encrypts serialized information using the application Sensitive Properties Key. + Review Comment: This paragraph does not apply in the same way to Registry, so it can be removed. ```suggestion ``` ########## nifi-registry/nifi-registry-core/nifi-registry-docs/src/main/asciidoc/administration-guide.adoc: ########## @@ -435,6 +492,36 @@ Here is an example certificate DN entry using the name John Smith: </authorizers> ---- +===== File-based (OIDC Authentication) +Here is an example as Initial User Identity called Test : Review Comment: Recommend changing this example user to `admin`: ```suggestion Here is an example as Initial User Identity called `admin` : ``` ########## nifi-registry/nifi-registry-core/nifi-registry-docs/src/main/asciidoc/administration-guide.adoc: ########## @@ -253,6 +253,63 @@ The `kerberos-identity-provider` has the following properties: See also <<kerberos_service>> to allow single sign-on access via client Kerberos tickets. +[[openid_connect]] +=== OpenID Connect + +OpenID Connect integration provides single sign-on using a specified Authorization Server. +The implementation supports the Authorization Code Grant Type as described in +link:https://www.rfc-editor.org/rfc/rfc6749#section-4.1[RFC 6749 Section 4.1^] and +link:https://openid.net/specs/openid-connect-core-1_0.html#CodeFlowSteps[OpenID Connect Core Section 3.1.1^]. + +After successful authentication with the Authorization Server, NiFi Registry generates an application Bearer Token with an +expiration based on the OAuth2 Access Token expiration. NiFi Registry stores authorized tokens using the local State +Provider and encrypts serialized information using the application Sensitive Properties Key. + +The implementation enables +link:https://openid.net/specs/openid-connect-rpinitiated-1_0.html[OpenID Connect RP-Initiated Logout 1.0^] when the +Authorization Server includes an `end_session_endpoint` element in the OpenID Discovery configuration. + +OpenID Connect integration supports using Refresh Tokens as described in +link:https://openid.net/specs/openid-connect-core-1_0.html#RefreshTokens[OpenID Connect Core Section 12]. +NiFi Registry tracks the expiration of the application Bearer Token and uses the stored Refresh Token to renew +access prior to Bearer Token expiration, based on the configured token refresh window. NiFi Registry does not require OpenID +Connect Providers to support Refresh Tokens. When an OpenID Connect Provider does not return a Refresh Token, NiFi Registry +requires the user to initiate a new session when the application Bearer Token expires. + +The Refresh Token implementation allows the NiFi Registry session to continue as long as the Refresh Token is valid and the +user agent presents a valid Bearer Token. The default value for the token refresh window is 60 seconds. For an Access +Token with an expiration of one hour, NiFi Registry will attempt to renew access using the Refresh Token when receiving an HTTP +request 59 minutes after authenticating the Access Token. Revoked Refresh Tokens or expired application Bearer Tokens +result in standard session timeout behavior, requiring the user to initiate a new session. + +The OpenID Connect implementation supports OAuth 2.0 Token Revocation as defined in +link:https://www.rfc-editor.org/rfc/rfc7009[RFC 7009^]. OpenID Connect Discovery configuration must include a +`revocation_endpoint` element that supports RFC 7009 standards. The application sends revocation requests for Refresh +Tokens when the authenticated Resource Owner initiates the logout process. + +The implementation includes a scheduled process for removing and revoking expired Refresh Tokens when the corresponding +Access Token has expired, indicating that the Resource Owner has terminated the application session. Scheduled session +termination occurs when the user closes the browser without initiating the logout process. The scheduled process avoids +extended storage of Refresh Tokens for users who are no longer interacting with the application. + +OpenID Connect integration supports the following settings in _nifi.properties_. Review Comment: ```suggestion OpenID Connect integration supports the following settings in _nifi-registry.properties_. ``` ########## nifi-registry/nifi-registry-core/nifi-registry-docs/src/main/asciidoc/administration-guide.adoc: ########## @@ -253,6 +253,63 @@ The `kerberos-identity-provider` has the following properties: See also <<kerberos_service>> to allow single sign-on access via client Kerberos tickets. +[[openid_connect]] +=== OpenID Connect + +OpenID Connect integration provides single sign-on using a specified Authorization Server. +The implementation supports the Authorization Code Grant Type as described in +link:https://www.rfc-editor.org/rfc/rfc6749#section-4.1[RFC 6749 Section 4.1^] and +link:https://openid.net/specs/openid-connect-core-1_0.html#CodeFlowSteps[OpenID Connect Core Section 3.1.1^]. + +After successful authentication with the Authorization Server, NiFi Registry generates an application Bearer Token with an +expiration based on the OAuth2 Access Token expiration. NiFi Registry stores authorized tokens using the local State +Provider and encrypts serialized information using the application Sensitive Properties Key. + +The implementation enables +link:https://openid.net/specs/openid-connect-rpinitiated-1_0.html[OpenID Connect RP-Initiated Logout 1.0^] when the +Authorization Server includes an `end_session_endpoint` element in the OpenID Discovery configuration. + +OpenID Connect integration supports using Refresh Tokens as described in +link:https://openid.net/specs/openid-connect-core-1_0.html#RefreshTokens[OpenID Connect Core Section 12]. +NiFi Registry tracks the expiration of the application Bearer Token and uses the stored Refresh Token to renew +access prior to Bearer Token expiration, based on the configured token refresh window. NiFi Registry does not require OpenID +Connect Providers to support Refresh Tokens. When an OpenID Connect Provider does not return a Refresh Token, NiFi Registry +requires the user to initiate a new session when the application Bearer Token expires. + +The Refresh Token implementation allows the NiFi Registry session to continue as long as the Refresh Token is valid and the +user agent presents a valid Bearer Token. The default value for the token refresh window is 60 seconds. For an Access +Token with an expiration of one hour, NiFi Registry will attempt to renew access using the Refresh Token when receiving an HTTP +request 59 minutes after authenticating the Access Token. Revoked Refresh Tokens or expired application Bearer Tokens +result in standard session timeout behavior, requiring the user to initiate a new session. + +The OpenID Connect implementation supports OAuth 2.0 Token Revocation as defined in +link:https://www.rfc-editor.org/rfc/rfc7009[RFC 7009^]. OpenID Connect Discovery configuration must include a +`revocation_endpoint` element that supports RFC 7009 standards. The application sends revocation requests for Refresh +Tokens when the authenticated Resource Owner initiates the logout process. + +The implementation includes a scheduled process for removing and revoking expired Refresh Tokens when the corresponding +Access Token has expired, indicating that the Resource Owner has terminated the application session. Scheduled session +termination occurs when the user closes the browser without initiating the logout process. The scheduled process avoids +extended storage of Refresh Tokens for users who are no longer interacting with the application. Review Comment: NiFi Registry does not currently support Refresh Tokens, so these paragraphs should be removed. ```suggestion ``` ########## nifi-registry/nifi-registry-core/nifi-registry-docs/src/main/asciidoc/administration-guide.adoc: ########## @@ -253,6 +253,63 @@ The `kerberos-identity-provider` has the following properties: See also <<kerberos_service>> to allow single sign-on access via client Kerberos tickets. +[[openid_connect]] +=== OpenID Connect + +OpenID Connect integration provides single sign-on using a specified Authorization Server. +The implementation supports the Authorization Code Grant Type as described in +link:https://www.rfc-editor.org/rfc/rfc6749#section-4.1[RFC 6749 Section 4.1^] and +link:https://openid.net/specs/openid-connect-core-1_0.html#CodeFlowSteps[OpenID Connect Core Section 3.1.1^]. + +After successful authentication with the Authorization Server, NiFi Registry generates an application Bearer Token with an +expiration based on the OAuth2 Access Token expiration. NiFi Registry stores authorized tokens using the local State +Provider and encrypts serialized information using the application Sensitive Properties Key. + +The implementation enables +link:https://openid.net/specs/openid-connect-rpinitiated-1_0.html[OpenID Connect RP-Initiated Logout 1.0^] when the +Authorization Server includes an `end_session_endpoint` element in the OpenID Discovery configuration. + +OpenID Connect integration supports using Refresh Tokens as described in +link:https://openid.net/specs/openid-connect-core-1_0.html#RefreshTokens[OpenID Connect Core Section 12]. +NiFi Registry tracks the expiration of the application Bearer Token and uses the stored Refresh Token to renew +access prior to Bearer Token expiration, based on the configured token refresh window. NiFi Registry does not require OpenID +Connect Providers to support Refresh Tokens. When an OpenID Connect Provider does not return a Refresh Token, NiFi Registry +requires the user to initiate a new session when the application Bearer Token expires. + +The Refresh Token implementation allows the NiFi Registry session to continue as long as the Refresh Token is valid and the +user agent presents a valid Bearer Token. The default value for the token refresh window is 60 seconds. For an Access +Token with an expiration of one hour, NiFi Registry will attempt to renew access using the Refresh Token when receiving an HTTP +request 59 minutes after authenticating the Access Token. Revoked Refresh Tokens or expired application Bearer Tokens +result in standard session timeout behavior, requiring the user to initiate a new session. + +The OpenID Connect implementation supports OAuth 2.0 Token Revocation as defined in +link:https://www.rfc-editor.org/rfc/rfc7009[RFC 7009^]. OpenID Connect Discovery configuration must include a +`revocation_endpoint` element that supports RFC 7009 standards. The application sends revocation requests for Refresh +Tokens when the authenticated Resource Owner initiates the logout process. + +The implementation includes a scheduled process for removing and revoking expired Refresh Tokens when the corresponding +Access Token has expired, indicating that the Resource Owner has terminated the application session. Scheduled session +termination occurs when the user closes the browser without initiating the logout process. The scheduled process avoids +extended storage of Refresh Tokens for users who are no longer interacting with the application. + +OpenID Connect integration supports the following settings in _nifi.properties_. + +[options="header"] +|================================================================================================================================================== +| Property Name | Description +|`nifi.registry.security.user.oidc.discovery.url` | The link:http://openid.net/specs/openid-connect-discovery-1_0.html[Discovery Configuration URL^] for the OpenID Connect Provider +|`nifi.registry.security.user.oidc.connect.timeout` | Socket Connect timeout when communicating with the OpenID Connect Provider. The default value is `5 secs` +|`nifi.registry.security.user.oidc.read.timeout` | Socket Read timeout when communicating with the OpenID Connect Provider. The default value is `5 secs` +|`nifi.registry.security.user.oidc.client.id` | The Client ID for NiFi Registry registered with the OpenID Connect Provider +|`nifi.registry.security.user.oidc.client.secret` | The Client Secret for NiFi Registry registered with the OpenID Connect Provider +|`nifi.registry.security.user.oidc.preferred.jwsalgorithm` | The preferred algorithm for validating identity tokens. If this value is blank, it will default to `RS256` which is required to be supported +by the OpenID Connect Provider according to the specification. If this value is `HS256`, `HS384`, or `HS512`, NiFi Registry will attempt to validate HMAC protected tokens using the specified client secret. +If this value is `none`, NiFi will attempt to validate unsecured/plain tokens. Other values for this algorithm will attempt to parse as an RSA or EC algorithm to be used in conjunction with the +JSON Web Key (JWK) provided through the jwks_uri in the metadata found at the discovery URL +|`nifi.registry.security.user.oidc.additional.scopes` | Comma separated scopes that are sent to OpenID Connect Provider in addition to `openid` and `email`. Authorization Servers require the `offline_access` scope to return a Refresh Token. Review Comment: ```suggestion |`nifi.registry.security.user.oidc.additional.scopes` | Comma separated scopes that are sent to OpenID Connect Provider in addition to `openid` and `email`. ``` ########## nifi-registry/nifi-registry-core/nifi-registry-docs/src/main/asciidoc/administration-guide.adoc: ########## @@ -435,6 +492,36 @@ Here is an example certificate DN entry using the name John Smith: </authorizers> ---- +===== File-based (OIDC Authentication) +Here is an example as Initial User Identity called Test : + +---- +<authorizers> + <userGroupProvider> + <identifier>file-user-group-provider</identifier> + <class>org.apache.nifi.registry.security.authorization.file.FileUserGroupProvider</class> + <property name="Users File">./conf/users.xml</property> + <property name="Initial User Identity 1">Test</property> Review Comment: ```suggestion <property name="Initial User Identity 1">admin</property> ``` ########## nifi-registry/nifi-registry-core/nifi-registry-docs/src/main/asciidoc/administration-guide.adoc: ########## @@ -435,6 +492,36 @@ Here is an example certificate DN entry using the name John Smith: </authorizers> ---- +===== File-based (OIDC Authentication) +Here is an example as Initial User Identity called Test : + +---- +<authorizers> + <userGroupProvider> + <identifier>file-user-group-provider</identifier> + <class>org.apache.nifi.registry.security.authorization.file.FileUserGroupProvider</class> + <property name="Users File">./conf/users.xml</property> + <property name="Initial User Identity 1">Test</property> + </userGroupProvider> + + <accessPolicyProvider> + <identifier>file-access-policy-provider</identifier> + <class>org.apache.nifi.registry.security.authorization.file.FileAccessPolicyProvider</class> + <property name="User Group Provider">file-user-group-provider</property> + <property name="Authorizations File">./conf/authorizations.xml</property> + <property name="Initial Admin Identity">Test</property> Review Comment: ```suggestion <property name="Initial Admin Identity">admin</property> ``` -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
