You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@nifi.apache.org by "marcelo225 (via GitHub)" <gi...@apache.org> on 2023/10/05 17:02:22 UTC
[PR] NIFI-12173 - Nifi Registry there's no documentation about OIDC connection [nifi]
marcelo225 opened a new pull request, #7842:
URL: https://github.com/apache/nifi/pull/7842
<!-- Licensed to the Apache Software Foundation (ASF) under one or more -->
<!-- contributor license agreements. See the NOTICE file distributed with -->
<!-- this work for additional information regarding copyright ownership. -->
<!-- The ASF licenses this file to You under the Apache License, Version 2.0 -->
<!-- (the "License"); you may not use this file except in compliance with -->
<!-- the License. You may obtain a copy of the License at -->
<!-- http://www.apache.org/licenses/LICENSE-2.0 -->
<!-- Unless required by applicable law or agreed to in writing, software -->
<!-- distributed under the License is distributed on an "AS IS" BASIS, -->
<!-- WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. -->
<!-- See the License for the specific language governing permissions and -->
<!-- limitations under the License. -->
# Summary
[NIFI-12173](https://issues.apache.org/jira/browse/NIFI-12173)
# Tracking
Please complete the following tracking steps prior to pull request creation.
### Issue Tracking
- [ ] [Apache NiFi Jira](https://issues.apache.org/jira/browse/NIFI) issue created
### Pull Request Tracking
- [ ] Pull Request title starts with Apache NiFi Jira issue number, such as `NIFI-12173`
- [ ] Pull Request commit message starts with Apache NiFi Jira issue number, as such `NIFI-12173`
### Pull Request Formatting
- [ ] Pull Request based on current revision of the `main` branch
- [ ] Pull Request refers to a feature branch with one commit containing changes
# Verification
Please indicate the verification steps performed prior to pull request creation.
### Build
- [ ] Build completed using `mvn clean install -P contrib-check`
- [ ] JDK 21
### Licensing
- [ ] New dependencies are compatible with the [Apache License 2.0](https://apache.org/licenses/LICENSE-2.0) according to the [License Policy](https://www.apache.org/legal/resolved.html)
- [ ] New dependencies are documented in applicable `LICENSE` and `NOTICE` files
### Documentation
- [ ] Documentation formatting appears as expected in rendered files
--
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: issues-unsubscribe@nifi.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] NIFI-12173 - Nifi Registry there's no documentation about OIDC connection [nifi]
Posted by "marcelo225 (via GitHub)" <gi...@apache.org>.
marcelo225 commented on PR #7842:
URL: https://github.com/apache/nifi/pull/7842#issuecomment-1766985402
@exceptionfactory I'm done with it!
--
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: issues-unsubscribe@nifi.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] NIFI-12173 - Nifi Registry there's no documentation about OIDC connection [nifi]
Posted by "exceptionfactory (via GitHub)" <gi...@apache.org>.
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: issues-unsubscribe@nifi.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] NIFI-12173 - Nifi Registry there's no documentation about OIDC connection [nifi]
Posted by "exceptionfactory (via GitHub)" <gi...@apache.org>.
exceptionfactory closed pull request #7842: NIFI-12173 - Nifi Registry there's no documentation about OIDC connection
URL: https://github.com/apache/nifi/pull/7842
--
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: issues-unsubscribe@nifi.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org