# KNIME服务器高级设置指南
# 介绍
本指南涵盖企业环境中KNIME Server部署,设置和配置的高级主题。
如果要安装KNIME Server,则应首先查阅《 KNIME Server安装指南》 (opens new window)。
有关从KNIME Analytics Platform连接到KNIME Server或使用KNIME WebPortal的指南,请参考以下指南:
有关所有常规管理配置选项和对KNIME服务器的基本了解,请参阅《 KNIME服务器管理指南》 (opens new window)。
在下文中,假定您具有前面提到的指南中涵盖的所有主题的知识。
# 企业用户认证
企业环境中的用户身份验证通常是通过一些集中式服务来完成的。最常用的服务是LDAP。在LDAP服务器可用的任何情况下,建议使用LDAP身份验证。如果您熟悉LDAP配置,则可以在安装期间添加详细信息,或在安装server.xml
后编辑文件。如果您不熟悉LDAP设置,则可能需要联系LDAP管理员,或使用组织中任何其他基于Tomcat的系统的配置详细信息。本节介绍如何设置KNIME Server进行LDAP身份验证。
用户身份验证的另一种可能性是单点登录。可以将KNIME Server配置为支持Kerberos身份验证和LDAP。本节还包含用于简单Kerberos设置的步骤。
# 为KNIME服务器配置LDAP连接
KNIME Server通过Apache Tomcat的内置机制管理所有用户身份验证。因此,用于配置身份验证的最全面的文档是 Apache Tomcat Realm Configuration HOW-TO (opens new window)。特别是有关LDAP(也是Active Directory)配置的信息,请参阅JNDIRealm (opens new window)部分。
术语
在整个文档中,我们指的是建立LDAP连接, LDAP帐户等。由于管理用户身份验证的一种流行方法是Microsoft Active Directory,它支持LDAP,因此您可能希望将LDAP帐户替换为Active Directory帐户。
# 快速开始
在大多数情况下,应该可以联系您本地的LDAP / Active Directory管理员;他们应该能够提供必要的信息。
您可以要求以下内容:
- 他们是否已经有Tomcat服务器的配置详细信息?如果是这样,则可以重新使用此连接信息。
- LDAP连接信息(主机名,端口,是否使用TLS / SSL?)。
- 他们是使用绑定模式还是比较模式。
- 组信息的存储方式。
他们将需要提供适合模板的配置,如下所示:
<Realm className =“ org.apache.catalina.realm.JNDIRealm”
connectionURL =“ ldap:// localhost:389”
userPattern =“ uid = {0},ou = people,dc = mycompany,dc = com”
roleBase =“ ou = groups,dc = mycompany,dc = com”
roleName =“ cn”
roleSearch =“(uniqueMember = {0})”
/>
此信息将添加到位于中的server.xml
文件中 /conf/server.xml
。
必须重新启动Apache Tomcat进程和KNIME Server,配置文件的更改才能生效。
# 进阶疑难排解
本文档的其余部分描述了如何为KNIME Server设置LDAP连接。这仅是将相关信息收集到一个地方的一种方式,而不是LDAP或Tomcat的全面文档。
第一个先决条件是Apache Directory Studio或其他一些LDAP配置工具。我们使用 Apache Directory Studio (opens new window)进行测试。使用此工具的好处是它是开源的,可以免费下载,并且可以在Windows / Linux / Mac上运行,因此客户可以下载该软件并进行查询以开始使用。
我们将遵循三个基本步骤:
- LDAP连接信息(主机名,端口,SSL?)。
- 他们是使用绑定模式还是比较模式。
- 组信息的存储方式。
# LDAP连接信息(主机名,端口,SSL)
要建立与LDAP服务器的连接,您需要了解以下内容:
- LDAP服务器主机名(或IP)
- 服务器是否使用SSL安全连接
- 使用哪个端口-默认端口
389
用于LDAP(未加密或由TLS加密)和636
LDAPS(受SSL保护)
# 设置Apache Directory Studio以浏览您的LDAP目录
# 建立与服务器的连接
# 添加您的LDAP服务器的连接详细信息
# 建立与LDAP服务器的连接
请注意,我们此处不使用身份验证。通常,您将需要进行身份验证,并且在大多数情况下,这可以是您的LDAP用户名和密码。
# 建立连接
您可以单击“获取基本DN”以自动填充答案。在我们的示例中,基本DN为dc=example,dc=com
。这将有所不同,例如knime.com可能使用基本DN dc=knime,dc=com
。
# 完成连接
您可以按原样保留下一页,然后单击完成。
# 浏览LDAP树
现在已填充LDAP浏览器,您可以开始浏览LDAP目录。
# 确定KNIME / Tomcat LDAP配置所需的信息
首先,请参考LDAP上 (opens new window)的 Tomcat文档 (opens new window)。文档非常全面,我们总结了以下一些关键点。有关完整的详细信息,请参考Tomcat文档。
基本上,我们需要构造类似以下内容的东西:
<Realm className =“ org.apache.catalina.realm.JNDIRealm”
connectionURL = “” ldap://52.50.222.127:389“
userPattern =待定
roleBase =待定
roleName =待定
roleSearch = TOBEDETERMINED
/>
我们已经知道了connectionURL
,因为这是设置Apache Directory Studio所必需的。
接下来,我们需要确定userBase
属性。树中的第一项通常是基本DN,它将定义userBase
属性。
您可以浏览树以找到用户。就我们而言ou=People
。展开子树将显示用户列表。在我们的例子中,有四个用户(ec2-user,ldapuser1,ldapuser2,ldapuser3)。
# 确定是通过绑定模式还是比较模式检查用户
# 绑定模式
在我们的例子中,如果用户以ldapuser1的身份登录(用户名与密钥相同)。
我们已经知道了基本DN,通过查看用户信息,我们可以看到uid是我们要用于认证的用户名。这样我们就可以构造userPattern
。
使用userPattern
:uid={0},ou=people,dc=example,dc=com
因此,示例如下所示:
<Realm className =“ org.apache.catalina.realm.JNDIRealm”
connectionURL =“ ldap://52.50.222.127:389”
userPattern = “ uid = {0},ou = people,dc = example,dc = com”
roleBase =待定
roleName =待定
roleSearch = TOBEDETERMINED
/>
需要注意的是,我们仍然不知道如何指定roleBase
,roleName
, roleSearch
。我们待会儿再讲。
# 比较模式
在这种情况下,登录名和用户名之间没有一对一的映射,我们想使用例如电子邮件地址类别。在此示例中为ldapuser1@example.com
。
要执行这种登录,我们需要比较模式:
在这里需要基本DN userBase
,我们还需要定义 userSearch
。在这里我们正在寻找mail
。
<Realm className =“ org.apache.catalina.realm.JNDIRealm”
connectionName = “ cn = Manager,dc = example,dc = com”
connectionPassword = “秘密”
connectionURL =“ ldap://52.50.222.127:389”
userBase = “ ou = people,dc = example,dc = com”
userSearch = “(mail = {0})”
userRoleName =“ memberOf”
roleBase =待定
roleName =待定
roleSearch = TOBEDETERMINED
/>
# 组访问
现在,用户已通过身份验证,我们需要配置具有访问权限的组:
为此,我们将需要roleBase
和roleName
参数。您可以浏览ou=Group
树以获取更多信息。这里以该hrpeople
组应该能够访问KNIME Server的示例为例。
在示例中,值是我们要搜索的成员是“成员”。
导致配置:
<Realm className =“ org.apache.catalina.realm.JNDIRealm”
connectionURL =“ ldap://52.50.222.127:389”
userBase =“ ou = people,dc = example,dc = com”
userSearch =“(mail = {0})”
userRoleName =“ memberOf”
roleBase = “ ou = Group,dc = example,dc = com”
roleName = “ cn”
roleSearch = “”(member = {0})“
/>
还有另一种可能性,即组成员身份存储在用户数据中(这是罕见的,本指南未涵盖。请参见完整的Tomcat文档)。
嵌套角色(角色/组可以包含其他角色/组)也是可能的,在这种情况下,请添加roleNested
参数。例如,“ IT”组包含一些用户名,以及“ Windows”,“ UNIX”,“ Mac”组。这些组也可以包含子组。
希望您现在有了将KNIME Server连接到LDAP所需的详细信息。
# Active Directory示例
如果您将Active Directory用作用户数据库并坚持默认结构,则以下配置是一个很好的起点:
<Realm className =“ org.apache.catalina.realm.JNDIRealm”
connectionName =“ cn = Manager,dc = example,dc = com”
connectionPassword =“ secret”
connectionURL =“ ldap://52.50.222.127:389”
userSubtree =“ true”
userBase =“ cn = Users,dc = domain,dc = com”
userSearch =“(sAMAccountName = {0})”
userRoleName =“ memberOf”
roleBase =“ cn = Users,dc = domain,dc = com”
roleName =“ cn”
roleSearch =“(成员= {0})”
roleSubtree =“ true”
roleNested =“ true” />
你必须调整三个突出的连接参数,以及两者dc
在价值观userBase
和roleBase
。其他参数通常可以照原样使用。
# 合并领域
可以在用户数据库和LDAP身份验证并行使用的情况下设置组合领域。通常不建议这样做,但对调试和初始设置/测试很有用。下面的示例显示了它如何工作。
<Realm className =“ org.apache.catalina.realm.LockOutRealm”>
<Realm className =“ org.apache.catalina.realm.UserDatabaseRealm”
resourceName =“ UserDatabase” />
<Realm className =“ org.apache.catalina.realm.JNDIRealm”
connectionURL =“ ldap://52.50.222.127:389”
userBase =“ ou = people,dc = example,dc = com”
userSearch =“(mail = {0})”
userRoleName =“ memberOf”
roleBase =“ ou = Group,dc = example,dc = com”
roleName =“ cn”
roleSearch =“(成员= {0})” />
</ Realm>
# 加密的LDAP
如果您使用的是加密的LDAP身份验证,而您的LDAP服务器使用的是自签名证书,则Tomcat将拒绝它。在这种情况下,您需要将LDAP服务器的证书添加到位于以下位置的全局Java密钥库中/lib/security/cacerts
:
keytool-导入-v-无提示-trustcacerts-文件
<服务器证书> -keystore <jre> / lib / security / cacerts -storepass changeit
或者,您可以复制cacerts
文件,添加服务器证书,并将以下两个系统属性添加到 /conf/catalina.properties
:
javax.net.ssl.trustStrore = <复制的密钥库>
javax.net.ssl.keyStorePassword =更改
# 故障排除
在某些情况下,您将希望提取有关LDAP身份验证过程的其他日志文件信息。在这种情况下,您可以编辑 apache-tomcat*/conf/logging.properties
以添加:
org.apache.catalina.realm.level =全部
org.apache.catalina.realm.useParentHandlers = true
org.apache.catalina.authenticator.level =全部
org.apache.catalina.authenticator.useParentHandlers = true
进行更改后,您将需要重新启动knime-server进程/服务。成功调试问题后,请勿忘记注释掉该行或从logging.properties
文件中删除这些行,因为这会创建不必要的大日志文件。
# 使用Kerberos和LDAP配置单点登录
可以为KNIME服务器配置单点登录。这包括WebPortal,还包括KNIME Server提供的所有其他服务(REST,SOAP等)。
用于实现此目的的技术是Kerberos,它是一种网络协议,用于通过票证和强加密进行身份验证。在下文中,假定您熟悉Kerberos和LDAP的基本概念,如前面部分所述。您可以在此处 (opens new window)找到有关Kerberos最新版本的全面文档 。
本节分步介绍了如何通过Active Directory服务和 Windows客户端来设置Kerberos身份验证。其他设置也是可能的,并且可能需要不同的过程才能起作用。
大多数设置会在某些方面与本指南有所出入,因此请在必要时进行调整。 | |
---|---|
Kerberos需要为所有涉及的三个方面进行设置:Kerberos和LDAP服务(活动目录),运行KNIME Server的Tomcat服务器以及客户端。
# Active Directory配置
第一步是正确设置Active Directory。假定您已经有一个Active Directory域,其中包含用户和正确的KNIME Server使用组。Kerberos特定的其他步骤是:
在LDAP中为Tomcat服务器创建一个技术用户。
将服务主体名称(SPN)与Tomcat服务器的新创建用户相关联。为此,请打开Windows PowerShell,然后输入:
setspn -s HTTP / TOMCAT_FQDN @ REALM TECHNICAL_USER
在上面的命令中,替换
TOMCAT_FQDN
使用运行KNIME服务器(以及Tomcat服务器)的机器的完全限定域名(FQDN),REALM
在Active Directory安装的Kerberos领域中,并
TECHNICAL_USER
使用您在上一步中创建的技术用户的名称。对于
TOMCAT_FQDN
DNS条目(从FQDN到IP)以及反向DNS条目(从IP到FQDN),域控制器和所有客户端都可以解析,这一点很重要。
确保正确的加密方法在域控制器上处于活动状态:
- 转到管理工具→本地安全策略
- 浏览到安全设置/本地策略/安全选项
- 查找条目网络安全性:配置Kerberos允许的加密类型。如果未定义该值,则允许所有加密类型。如果它被定义,确保它至少包含方法:
RC4_HMAC
,AES128
,AES256
和Future Encryption Types
。
打开Windows PowerShell并
keytab
使用以下命令创建文件。根据您的设置调整值:ktpass / out PATH / tomcat.keytab / mapuser TECHNICAL_USER @ REALM / princ HTTP / TOMCAT_FQDN @ REALM /通行证+ rndPass / crypto AES256-SHA1 ptype KRB5_NT_PRINCIPAL
创建的密钥表文件需要稍后再复制到Tomcat服务器。
在Active Directory中为您创建的技术Tomcat用户打开“用户属性”。然后转到“帐户”标签,并确保设置了以下设置:
- 用户登录名设置正确
- 密码永不过期=
true
- 用户无法更改密码=
true
- 此帐户支持Kerberos AES 128位加密=
true
- 此帐户支持Kerberos AES 256位加密=
true
- 为此帐户使用Kerberos DES加密=
false
(推荐)
然后转到“委托”选项卡,并将单选按钮设置为“信任此用户以委托给任何服务(仅Kerberos)”
# Tomcat服务器配置
按照《KNIME服务器安装指南》 (opens new window)中的概述安装KNIME Server 。
按照《KNIME服务器管理指南》 (opens new window)中的说明进行适当的配置调整。
server.xml
如中的“为KNIME服务器配置LDAP连接”中 (opens new window)所述,在中设置LDAP身份验证以连接到Active Directory 。请注意,可能有必要创建一个临时列表用户来执行LDAP查找。此步骤是可选的,但建议您测试基本LDAP身份验证是否正常运行。验证
JAVA_HOME
并CATALINA_HOME
正确定义了环境变量:JAVA_HOME
应该指向JDK8主目录(包含一个bin
文件夹)CATALINA_HOME
应该指向Tomcat目录(包含一个bin
文件夹)。
在Windows上,可以在控制面板→系统→高级系统设置中完成此操作
- 单击环境变量
- 在对存在的系统变量组检查
JAVA_HOME
和CATALINA_HOME
。相应地创建或调整值。
在Linux上,创建或更改
/etc/default/knime-server
验证了可以使用的标准LDAP设置后,
/conf
通过将的内容复制到进行备份/conf_ldap
。在Windows上,打开regedit并执行以下操作:
导航至
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa\Kerberos\Parameters
。添加键
allowtgtsessionkey
(REG_DWORD
)并将其值设置为1
。
在Windows上,确保Kerberos的正确加密方法处于活动状态:
转到管理工具→本地安全策略
浏览到安全设置/本地策略/安全选项
查找条目网络安全:配置Kerberos允许的加密类型
如果未定义该值,则允许所有加密类型。如果它被定义,确保它至少包含方法:
RC4_HMAC
,AES128
,AES256
和Future Encryption Types
。
为JDK8安装Java密码学扩展(JCE)无限强度管辖权策略文件:
- 从Oracle网站 (opens new window)下载档案
- 在Java 8 JRE位置(
jre/lib/security
和jdk/jre/lib/security
)中创建安全策略文件的备份。 - 将归档文件解压缩到Java 8 JRE位置(
jre/lib/security
和jdk/jre/lib/security
),替换那些目录中的文件。
将先前为SPN创建的keytab文件复制到您选择的位置。推荐是
/conf/
在中创建
krb5.ini
文件/conf/
。该文件的内容应类似于:[libdefaults] default_realm =真实 default_keytab_name =“ FILE:<CATALINA_HOME> /conf/tomcat.keytab” default_tkt_enctypes = aes256-cts-hmac-sha1-96,aes128-cts-hmac-sha1-96 default_tgs_enctypes = aes256-cts-hmac-sha1-96,aes128-cts-hmac-sha1-96 转发=真 [领域] 领域= { kdc = DOMAIN_CONTROLLER_FQDN:88 } [domain_realm] yourdomain.com = REALM * .yourdomain.com = REALM
根据您的配置调整值,但保留
FILE:
密钥表名称的前缀。如果要为此文件使用其他位置或文件名,可以通过在以下文件中定义以下Java系统属性来实现/conf/system.properties
:java.security.krb5.conf = PATH_TO_KRB5_CONF
创建或编辑文件
/conf/jaas.conf
。该文件的内容应类似于:com.sun.security.jgss.krb5.accept { com.sun.security.auth.module.Krb5LoginModule 需要 doNotPrompt = true 主体=“ HTTP / TOMCAT_FQDN @ REALM” keyTab =“ <CATALINA_HOME> /conf/tomcat.keytab” storeKey = true useKeyTab = true useTicketCache = true isInitiator = true refreshKrb5Config = true moduleBanner = true storePass = true; }; com.sun.security.jgss.krb5.initiate { com.sun.security.auth.module.Krb5LoginModule 需要 doNotPrompt = true 主体=“ HTTP / TOMCAT_FQDN @ REALM” keyTab =“ <CATALINA_HOME> /conf/tomcat.keytab” storeKey = true useKeyTab = true useTicketCache = true isInitiator = true refreshKrb5Config = true moduleBanner = true storePass = true; };
根据您的配置调整值。请注意,即使在Windows上,密钥表文件的位置也必须作为绝对路径给出并且包含正斜杠。
如果要使用其他位置或文件名,
jaas.conf
可以通过在中定义以下Java系统属性来实现/conf/system.properties
:java.security.auth.login.conf = PATH_TO_JAAS_CONF
在Kerberos文档中,此文件通常称为
login.conf
。在启动时,将以下属性添加到JVM系统属性列表中。它们可以在以下位置定义
/conf/system.properties
:javax.security.auth.useSubjectCredsOnly = false
配置
KNIMEServerAuthenticator
阀门:导航
/conf/Catalina/localhost/
编辑
knime.xml
文件(文件名等于在KNIME Server安装程序中设置的上下文根,默认值为knime
,如果将knime.war
文件重命名为renamed.war
,则将调用xml文件renamed.xml
)找到线
<Valve className =“ com.knime.enterprise.tomcat.authenticator.KnimeServerAuthenticator” enableSpnego =“ false” basicAuthPaths =“ / rest,/ webservices” formAuthPaths =“ /” />
更改为
<Valve className =“ com.knime.enterprise.tomcat.authenticator.KnimeServerAuthenticator” enableSpnego =“ true” basicAuthPaths =“ / rest,/ webservices” />
默认情况下,REST和SOAP Web服务设置为使用基本HTTP身份验证。如果您还希望对REST和/或SOAP Web服务也使用“单点登录”,例如,如果您正在使用支持Kerberos的REST客户端,请相应地调整
basicAuthPaths
属性。它是用逗号分隔的路径列表,用于覆盖默认的身份验证方法。删除属性将为所有服务启用Kerberos。例如,如果应该将REST与单一登录一起使用,则属性将如下所示:
basicAuthPaths="/webservices"
修改
server.xml
和调整JNDIRealm
设置以连接到LDAP。如果您已在步骤3中成功测试了设置,则只需删除connectionName
和connectionPassword
属性即可。请注意,使用Kerberos时,
connectionName
andconnectionPassword
属性将被忽略。另外,使用userPattern
Kerberos时,Tomcat不支持使用。使用userBase
结合userSearch
来代替。领域定义可能如下所示:
<Realm className =“ org.apache.catalina.realm.JNDIRealm” connectionURL =“ ldap://dc.domain.com:3268” userSubtree =“ true” userBase =“ cn =用户,dc =域,dc = com” userSearch =“(sAMAccountName = {0})” userRoleName =“ memberOf” roleBase =“ cn =用户,dc =域,dc = com” roleName =“ cn” roleSearch =“(成员= {0})” roleSubtree =“ true” roleNested =“ true” />
如果在组合领域中使用Kerberos,请确保连接到LDAP的JNDIRealm在领域列表中排在首位。
重新启动KNIME Server,以使更改生效。检查日志文件,
/logs
以确保没有与您的更改有关的错误消息。
# 客户端配置
客户端配置需要两个步骤:
- 客户端计算机必须是域的一部分,最终用户必须登录到该域。
- 客户端使用的所有浏览器都需要启用Kerberos身份验证。以下各节介绍如何对Internet Explorer和Firefox进行Kerberos身份验证。
# 在Internet Explorer中启用Kerberos身份验证
打开“ Internet选项”菜单,然后浏览到“高级”选项卡。
需要检查“启用集成Windows身份验证”设置。
浏览到“安全性”选项卡,选择“本地Intranet”,然后单击“站点”按钮。
单击“高级”,然后将KNIME Server的URL添加到区域中的网站列表中。
单击“自定义级别”,然后检查“*本地Intranet安全级别”→“用户身份验证”*是否设置为“仅在Intranet区域中自动登录”
可能还需要将KNIME Server添加到受信任的站点列表中。为此,请转到“受信任的站点”,然后单击“站点”按钮。将KNIME Server的URL添加到区域中的网站列表中。
检查“*可信站点安全级别”→“用户身份验证”*是否设置为“使用当前用户名和密码自动登录”。
# 在Firefox中启用Kerberos身份验证
启动Firefox,然后
about:config
在地址栏中输入。通过单击“我会小心,我保证!”来忽略警告。按钮。
通过
network.negotiate-auth
在搜索字段中键入来找到适当的设置。更改
network.negotiate-auth.delegation-uris
和,network.negotiate-auth.trusted-uris
以包含KNIME服务器的URL。只需输入您的域就足够了。
# 故障排除
Kerberos设置通常非常复杂,需要精确配置。错误消息通常是含糊不清的。要调试Kerberos设置,为Tomcat服务器中的身份验证启用附加日志记录非常有帮助。为此,您可以配置一些东西。
要启用Krb5模块中的日志记录,请在
jaas.conf
(或login.conf
中的/conf
)两个部分中添加或启用以下两行:debug = true moduleBanner = true
请注意,调试输出仅打印到控制台。
要增加Java中Kerberos实现的调试输出,请在启动时添加以下系统属性(可以在中的
system.properties
文件中 完成/conf
):-Dsun.security.krb5.debug = true
通过将身份验证和领域模块添加到中的
logging.properties
文件来添加调试/conf
。为了清楚起见,所有身份验证输出都可以登录到单独的文件中。[...] 4auth.org.apache.juli.FileHandler.level =精细 4auth.org.apache.juli.FileHandler.directory = $ {catalina.base} / logs 4auth.org.apache.juli.FileHandler.prefix =身份验证。 [...] org.apache.catalina.realm.level =全部 org.apache.catalina.realm.handlers = 4auth.org.apache.juli.FileHandler org.apache.catalina.authenticator.level =全部 org.apache.catalina.authenticator.handlers = 4auth.org.apache.juli.FileHandler com.knime.enterprise.tomcat.handlers = 4auth.org.apache.juli.FileHandler com.knime.enterprise.tomcat.level =调试 org.apache.juli.logging.UserDataHelper.CONFIG = INFO_ALL org.apache.coyote.http11.level =调试 org.apache.coyote.http11.handlers = 4auth.org.apache.juli.FileHandler
# 服务器管理的自定义的动态配置文件
如《KNIME服务器管理指南》中所述 (opens new window) ,可以编写自定义配置文件提供程序,以动态选择服务器和配置文件列表。此自定义提供程序必须是插件中org.knime.product.profiles.IProfileProvider
包含的接口的实现 org.knime.product
。此接口的实现不能使用任何触发读取首选项的类,否则默认首选项将无法再更改。这包括使用常用的KNIME类,例如KNIMEConstants
或NodeLogger
。
因此,我们建议创建一个新插件,该插件仅依赖于 org.knime.product
(对于IProfileProvider
接口),否则不使用任何其他KNIME类。org.knime.core.util
插件中的类是一个例外 ,因为它不使用任何首选项(并且永远不会使用)。除此之外,实现是直接的。该类 org.knime.product.profiles.ExampleProfileProvider
包含一个自定义配置文件提供程序的最小示例,您可以将其用作起点。不要忘记在扩展点注册实现 org.knime.product.profileProvider
。
如果您对实现自定义配置文件提供程序有任何疑问,请随时与我们联系。
# OpenID Connect身份验证
可以将KNIME服务器配置为使用启用了OpenID Connect的身份提供程序进行身份验证。
启用并配置该功能后,已认证用户将被映射到KNIME Server用户。
# OpenID Connect(OAuth)的认证阀配置
要为KNIME服务器启用OAuth身份验证,必须编辑文件
可以配置服务器,以便可以同时使用凭据使用OAuth和基本身份验证。对于配置,可以将以下参数添加到验证阀的定义中:
enableOAuth="" 启用OAuth身份验证。默认值为false(禁用OAuth身份验证)。 |
---|
enableBasicAuthWithOAuth="" 如果启用了OAuth,则在OAuth旁边启用基本身份验证。默认值为false(使用OAuth时禁用基本身份验证)。启用此选项后,REST客户端和KNIME Analytics平台仍可以使用用户的凭据(用户名和密码)进行身份验证。只有通过身份提供商使用OAuth才能登录到WebPortal。 |
oAuthConfigurationPath="" 配置文件的路径。推荐的位置是 |
阀门条目应类似于以下内容:
<Valve className =“ com.knime.enterprise.tomcat.authenticator.KnimeServerAuthenticator”
enableSpnego =“ false” basicAuthPaths =“ / rest” formAuthPaths =“ /”
secretKey =“ someSecreKey” enableOAuth =“ true” enableBasicAuthWithOAuth =“ false”
oAuthConfigurationPath="/path/to/conf/Catalina/localhost/knime-oidc-config.json"/>
The provider-specific configuration is done by creating a knime-oidc-config.json file and placing it in according to the path configured in
Here is an example of such a file, the parameters are explained below:
{
"identity-provider-name" : "Some Identity Provider",
"auth-server-url": "https://identitiy.provider/",
"resource": "client-id",
"credentials": {
"secret" : "client-secret"
},
"additional-authorization-endpoint-parameters": "&additional-parameter=some-value&some-other-parameter=some-value",
"additional-scopes": "additional-scope another-scope",
"principal-attribute": "claim-used-for-principal-mapping"
}
The authenticator is capable of discovering the necessary OpenID Connect endpoints automatically. It does so by using the auth-server-url and inspecting the ".well-known/openid-configuration" endpoint if it is available. If the discovery fails the endpoints must be set explicitly.
identity-provider-name="" The name of the Identity provider to be displayed on the login landing page as "Login using |
---|
auth-server-url="" 身份提供者的OpenID Connect终结点的基本URL。根据OpenID Connect发现 (opens new window),此端点用于自动端点 发现 (opens new window)。 |
authorization-endpoint="" (可选)身份提供者的授权端点。如果自动端点发现失败,则必须明确设置。 |
token-endpoint="" (可选)身份提供者的令牌端点。如果自动端点发现失败,则必须明确设置。 |
jwks-endpoint="" (可选)用于验证JWT令牌的JWKS端点。如果自动端点发现失败,则必须明确设置。 |
userinfo-endpoint="" (可选)身份提供者的userinfo端点。如果自动端点发现失败,则必须明确设置。 |
resource="" 应用程序的客户端ID。 |
credentials-secret="" (可选)必须为身份提供者设置的客户端机密。 |
public-client="" (可选)如果不需要客户端凭据,请设置为“ true”。 |
additional-authorization-endpoint-parameters="&" (可选)调用身份提供者的授权端点时使用的其他参数。 |
additional-scopes=" " 以空格分隔的其他范围列表,在调用身份提供程序的授权端点时应请求这些范围。在OpenID的交谈授权端点范围时,总是使用。 |
principal-attribute="" 应该用于将经过身份验证的用户映射到tomcat领域的声明。该声明还用作访问KNIME服务器的用户的帐户名。默认情况下,它将使用子声明。该昵称要求可用于例如,在这种情况下,确保相应的范围要求,要求授权端点时。 |
minimal-access-token-parsing="" 如果由于访问声明之一格式错误或与规范不符而无法验证访问令牌(请参阅 https://openid.net/specs/openid-connect-core-1_0.html),则解析访问令牌可以保持在最低限度,因此仍可以验证令牌的签名和发行者。 |
allow-opaque-access-token="" 如果身份提供者不能像JWT一样提供访问令牌,则无法通过检查其声明或验证其签名来验证不透明令牌。然后,通过调用userinfo端点将验证留给身份提供者。不建议这样做,但这是为不提供JWT访问令牌的身份提供程序启用兼容性的唯一方法。 |
treat-access-token-as-opaque="" 如果无法验证访问令牌的签名,因为它不遵循规范,例如,因为它包含需要专门用于签名验证的标头,则可以将这些令牌视为不透明的。在这种情况下,不会解析访问令牌,并且不会验证其签名和颁发者。然后,通过调用userinfo端点将验证留给身份提供者。不建议这样做,但是对于不兼容OIDC规范的不兼容的身份提供程序,它可以作为一种解决方法。如果此选项设置为“ true”,则最小访问令牌解析以及allow-opaque-access-token选项都将被忽略。 |
principal-attribute-to-username-regex="" (可选)可以使用正则表达式修改主体属性。例如,如果电子邮件声明被配置为主体属性,则可以使用正则表达式“ @ company.com”将类似john.doe@company.com的电子邮件映射到john.doe。匹配正则表达式的主体属性的第一个子字符串将被删除。 |
`redirect-rewrite-rules="(可选)可能需要,指定重定向URI重写规则。这是一个对象表示法,键是要与重定向URI匹配的正则表达式,值是替换字符串。 |
# 用户和组管理
启用该功能后,将使用来自userinfo端点的可配置声明将用户映射到KNIME Server中的帐户。例如,如果选择了声明 昵称,将其命名为“ john.doe”,则该用户将被映射到用户名为“ john.doe”的内部用户。
# 限制登录组
默认情况下,所有通过身份验证的用户都可以登录KNIME服务器。如果应该限制访问,则可以在KNIME服务器配置文件中 (opens new window)定义允许的登录组 ,这样,未分配给任何组的用户将无法登录服务器。
添加以下配置选项,会将登录限制为指定的组:
com.knime.server.login.allowed_groups =,,…
定义允许登录到服务器的组。默认值允许所有组的用户。
# Tomcat组管理
默认情况下,组管理由tomcat领域处理。这样,仍然可以根据 《KNIME服务器管理指南》 (opens new window)中的“用户身份验证” (opens new window)部分配置tomcat领域 。请注意,在tomcat领域中为用户设置的密码与OAuth身份验证无关。只要定义的声明与数据库中的用户名匹配,该用户就会使用分配的组登录。
# LDAP配置
将JNDIRealm用于LDAP也是有效的配置,只要可以将映射用户名的主体属性映射到LDAP中的条目即可。使用主体属性电子邮件的用户/组查找有效配置如下所示:
<Realm className =“ org.apache.catalina.realm.CombinedRealm”>
<Realm className =“ org.apache.catalina.realm.UserDatabaseRealm”
resourceName =“ UserDatabase” />
<Realm className =“ org.apache.catalina.realm.JNDIRealm”
connectionURL =“ ldap://ldap.hostname:389”
userBase =“ ou =人员,dc =公司,dc = com”
userSearch =“(电子邮件= {0})”
roleBase =“ ou = groups,dc = company,dc = com” roleName =“ cn”
roleSearch =“(成员= {0})” />
</ Realm>
有关设置LDAP的更多信息,请参阅《 KNIME服务器高级设置指南》 (opens new window)。
# 组映射声明
身份验证器也可以配置为将从用户信息端点检索的自定义声明映射到用户组。例如,这可能是一个称为“组”的声明。可以通过使用以下参数在knime-oidc-config.json中定义声明来启用组检索:
group-mapping-claim=""
在userinfo端点为用户提供一组组的声明的名称。确保适当定义范围,以便可以检索索赔。
如果启用了组映射声明,则不使用tomcat领域。
# KNIME Analytics Platform的KNIME Server客户端配置
为了为配置为OpenID Connect的KNIME服务器的客户端启用OAuth身份验证,必须将其他一些配置添加到
默认情况下,使用knime-oidc-config.json配置端点,客户端ID和客户端密码。
下面显示了附加配置的外观,配置参数如下所述:
com.knime.server.authentication.oauth.redirect_ports = 8888,8881,8882
com.knime.server.authentication.types = OAuth,凭据
com.knime.server.authentication.preferredType = OAuth
com.knime.server.authentication.oauth.token_refresh_rate = 5m
com.knime.server.authentication.types=, 逗号分隔的身份验证类型列表。可能的值为“ OAuth”和“凭据”。这应该与 |
---|
com.knime.server.authentication.preferredType= KNIME Analytics Platform应该使用的首选身份验证类型。将KNIME服务器添加为KNIME Analytics Platform中的新安装点时,将首选类型。可能的值为“ OAuth”和“凭据”。这应与中定义的身份验证类型匹配com.knime.server.authentication.type 。 |
com.knime.server.authentication.oauth.redirect_ports=,, 以逗号分隔的端口列表,应用于授权重定向。如果未给出列表,则将为每个授权选择一个随机端口。某些身份提供程序可能不支持通配符,在这种情况下,应在此处提供已配置端口的列表。 |
com.knime.server.authentication.oauth.token_refresh_rate= (可选)如果访问令牌是不透明的,则无法确定访问令牌的到期日期,因此可以引入刷新率来刷新令牌。 |
com.knime.server.authentication.oauth.client_secret= (可选)仅在身份提供程序要求时使用此选项。KNIME Analytics Platform必须使用该客户端密钥才能对身份提供者进行身份验证。 |
com.knime.server.authentication.oauth.authorization_endpoint= (可选,从knime-odic-config.json提供)身份提供者的授权端点。 |
com.knime.server.authentication.oauth.token_endpoint= (可选,从knime-odic-config.json提供)身份提供者的令牌端点。 |
com.knime.server.authentication.oauth.client_id= (可选,从knime-odic-config.json提供)应用程序的客户端ID。 |
com.knime.server.authentication.oauth.scope=,, (可选,从knime-odic-config.json提供)调用身份提供者的授权端点时应请求的其他范围的逗号分隔列表。范围应与服务器端knime-oidc-config.json中的范围匹配。所述的OpenID范围应在任何情况下提供,与附加范围在knime-OIDC-config.json还限定沿。 |
com.knime.server.authentication.oauth.additional_query_params= (可选,从knime-odic-config.json提供)调用身份提供者的授权端点时应使用的其他参数,以查询字符串的形式提供。 |
# 调试OIDC身份验证
为了启用日志记录,以调试身份验证问题,必须对
首先,必须将处理程序4auth.org.apache.juli.FileHandler添加到处理程序列表中:
handlers = 4auth.org.apache.juli.FileHandler,....
其次,此处理程序的日志级别应设置为ALL:
4auth.org.apache.juli.FileHandler.level =全部
4auth.org.apache.juli.FileHandler.directory = $ {catalina.base} / logs
4auth.org.apache.juli.FileHandler.prefix =身份验证。
4auth.org.apache.juli.FileHandler.maxDays = 90
最后,关于身份验证的块应取消注释:
org.apache.catalina.realm.level =全部
org.apache.catalina.realm.handlers = 4auth.org.apache.juli.FileHandler
org.apache.catalina.authenticator.level =全部
org.apache.catalina.authenticator.handlers = 4auth.org.apache.juli.FileHandler
com.knime.enterprise.tomcat.handlers = 4auth.org.apache.juli.FileHandler
com.knime.enterprise.tomcat.level =调试
org.apache.juli.logging.UserDataHelper.CONFIG = INFO_ALL
org.apache.coyote.http11.level =调试
org.apache.coyote.http11.handlers = 4auth.org.apache.juli.FileHandler
使用此日志记录配置,可以在