安全声明标记语言 (SAML) 身份验证
可将 SAML 2.0 身份验证集成到 Windchill 中，以允许参与联合单一登录解决方案。本主题假设您具有 SAML 2.0 规范的必备知识。有关详细信息，请参阅由 OASIS Security Services 技术委员会发布的 SAML v2.0 文档，可在 https://www.oasis-open.org/standards#samlv2.0 中找到。
Windchill 身份验证策略依赖于 Web 服务器强制进行身份验证。以下过程将介绍将 Shibboleth 服务提供者与 PTC HTTP Server 搭配使用的集成方案的 PTC 测试，用于确认 Windchill 与 SAML 的兼容性。有关 Windchill 安装所支持的 Shibboleth 版本的信息，请参阅发布日历，然后单击 View matrix page。测试在特定条件下执行并作为示例配置提供。每个站点都具有实现 SAML 的唯一方法。最多可为每个客户选择一个 SAML 服务提供者。PTC 仅对 Shibboleth 服务提供者的适用性进行测试和验证，不会对其他 SAML 服务提供者适用性作出任何保证。PTC 不直接支持 SAML 服务提供者的设置或配置。有关配置所选 SAML 服务提供者的帮助，请参阅该产品的文档或客户支持。此过程不会解决如何在联合中建立或配置标识提供者的问题。有关建立标识提供者的信息，请参阅 OASIS 或 Shibboleth 文档，或者咨询您的标识提供者管理员。
大多数单点登录解决方案使用 SAML Web 浏览器 SSO 配置文件。在这种情况下，至少有三个角色。
|
角色
|
说明
|
|---|---|
|
用户代理
|
代表自然用户从服务提供者发出请求的浏览器客户端。
|
|
服务提供者
|
向联合中的其他实体提供服务的实体。用户代理代表承担者向服务提供者发出请求。
|
|
标识提供者
|
标识提供者 (IdP) 创建、维护和管理承担者的标识信息，并为承担者访问联合内的各个服务提供身份验证。
|
上述以及其他角色的详细信息将在 OASIS SAML v2.0 文档中介绍。下图用于描述角色之间的身份验证过程。
可以将一个标识提供者配置为其他标识提供者的服务提供者。当此过程引用标识提供者时，它仅引用服务提供者必须直接与其进行通信的标识提供者，而不会引用任何其他联合标识提供者。
要为使用 Shibboleth 服务提供工具的 Windchill 启用 SAML 功能，需要执行以下步骤。
 | 不支持将 Shibboleth 用作 Windchill Business Reporting 的标识管理软件。 |
1. 安装 Shibboleth 服务提供者
Shibboleth 可从 Shibboleth Consortium 下载。使用以下资源下载 Shibboleth 并安装在与 PTC HTTP Server 相同的系统上。
Shibboleth 安装文件 |
对于 Linux，Shibboleth 服务提供工具可以通过 yum 信息库进行安装。有关详细信息，请参阅 Shibboleth 安装文档。
安装后，必须为您的站点配置 Shibboleth。
2. 配置 Shibboleth 服务提供者
要配置 Shibboleth 服务提供者，必须编辑两个 XML 文件。
a. 编辑位于 shibboleth_install_directory/etc/shibboleth/shibboleth2.xml 的 shibboleth2.xml。在 Linux 上，shibboleth_install_directory 目录是 / 目录。
以下是最低配置更改要求。
▪ 配置服务提供者的唯一 entityID。这由 <ApplicationDefaults> 标记的 entityID 属性进行配置。默认值为 "https://sp.example.org/shibboleth"。entityID 需要是标识服务提供者的唯一字符串。URL 可能具有足够的唯一性。例如：<ApplicationDefaults entityID="https://windchillserver.company.com"。
▪ 配置 sessionHook 特性以添加采用值 "/Windchill/sso/shibboleth/sessionHook" 的 <ApplicationDefaults> 标记，如下所示：
<ApplicationDefaults sessionHook="/Windchill/sso/shibboleth/sessionHook"
▪ 必须配置 REMOTE_USER 属性以允许将其传递到 Windchill 服务器。
配置 <ApplicationDefaults> 元素的 REMOTE_USER 属性，该元素用于定义传递到 Web 应用程序的 SAML 属性。此属性采用以空格分隔的子属性字符串的格式，其中每个子属性都是在 attribute-map.xml 文件中映射的 ID。属性字符串按此过程稍后介绍的 attribute-map.xml 配置向 Shibboleth 服务提供者公开。将使用第一个返回非空值的属性名称。例如，如果您已将属性映射配置为使用属性名称 ‘uid’ 来返回 REMOTE_USER 的值，则 REMOTE_USER 配置必须为 REMOTE_USER="uid"。
有关详细信息，请参阅有关 NativeSPApplication 的 Shibboleth 服务提供者文档。
▪ 将 SSO entityID 配置为与标识提供工具的 entityID 相匹配。这由 <SSO> 标记的 entityID 属性配置。默认值为：https://idp.example.org/idp/shibboleth。必须将 entityID 替换为标识提供者所提供的值。有关此值的信息，请咨询您的标识提供者管理员。如果值为 "MyIDP"，则配置将为：<SSO entityID="MyIDP">。
▪ 配置特性 postArtifact、template 和 outgoingBindings 以添加 <SSO> 标记。这些特性的值如以下示例所示：
<SSO postArtifact="true" template="bindingTemplate.html" outgoingBindings="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
▪ 为标识提供者配置元数据
Shibboleth 服务提供者必须有权访问 XML 格式的标识提供者元数据。某些标识提供者需要以 XML 文件格式导出元数据，而其他标识提供者则允许使用 URL 访问元数据。请咨询您的标识提供者管理员或查阅厂商文档，以确定向 Shibboleth 服务提供者提供元数据的适当方法。
▪ 如果元数据作为 XML 文件提供，请在 shibboleth2.xml 文件的主文档中添加以下标记：<MetadataProvider type="XML" validate="true" path="<元数据 xml 文件的位置>"/>，将 “元数据 xml 文件的位置” 替换为您的元数据文件的位置。如果元数据文件与 shibboleth2.xml 文件位于同一目录中，则只需要文件名。
▪ 如果元数据可通过 URL 访问，则该元数据可以使用下列标记加载：<MetadataProvider type="XML" validate="true" uri="<IDP 元数据的 url>" backingFilePath="federation-metadata.xml"/>。BackingFilePath 允许您使用本地保存的元数据副本，以防无法访问 URL。
Shibboleth 服务提供者文档还提供了适用于生产环境配置的其他属性。
b. 编辑位于 shibboleth_install_directory/opt/shibboleth/sp/etc/shibboleth/attribute-map.xml 的 attribute-map.xml 文件。
必须配置此属性映射文件才能处理属性声明。属性通过名称和格式向 SAML 服务提供者公开。名称可以是实际属性名称，也可以是名称空间。属性声明格式是 SAML 规范的一部分。有关属性命名管理的详细信息，请参阅 Shibboleth 服务提供者文档中 NativeSPConfiguration 下有关 NativeSPAttributeExtractor 和 NativeSPAddAttribute 的部分。
通常情况下，IdP 使用由已命名字符串标识的名称格式 "urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified" 来声明属性。例如，"uid"。在本示例中，以下配置会将 IdP 中的 uid 值映射到用于 REMOTE_USER 的 uid 字符串：
<Attribute name="uid" id="uid"/>
有关使用特定名称空间或名称格式的更复杂方案，请参阅 Shibboleth 文档。有关标识提供者中属性声明的具体信息，请咨询您的 IdP 管理员。
3. 编辑位于 shibboleth_install_directory/etc/shibboleth 的 bindingTemplate.html 文件。在 Linux 上，shibboleth_install_directory 目录是 / 目录。
如果已实施自定义配置，请将自定义更改与 bindingTemplate.html 更改进行合并。PTC 建议您在合并更改之前对自定义进行备份。
示例 bindingTemplate.html 提供在 $WT_HOME/codebase/WEB-INF/templates/sso/shibboleth 处，仅用作参考目的。
 | 请勿将示例文件 bindingTemplate.html 从 Windchill 安装目录复制到 Shibboleth 目录。 |
该示例 bindingTemplate.html 包含以下代码：
<!-- PTC Recommended Customization(1) Start -->
<body onload="submit();">
<!-- PTC Recommended Customization(1) End -->
…
<!-- PTC Recommended Customization(2) Start -->
<script type="text/javascript">
/**
*Saves the URL fragment to session store, if it is available in browsers address bar
*/
function saveURLFragment() {
var URL_FRAGMENT_KEY = 'WINDCHILL_SSO_URL_FRAGMENT';
var windchillStore = window.sessionStorage;
if (windchillStore) {
var hash = document.location.href.split('#')[1];
if (hash && hash.length > 0) {
windchillStore.setItem(URL_FRAGMENT_KEY, hash);
} else {
// clean-up, if left by previous incomplete login attempt.
windchillStore.removeItem(URL_FRAGMENT_KEY);
}
}
}
function submit() {
saveURLFragment();
document.forms[0].submit();
}
</script>
<!-- PTC Recommended Customization(2) End -->
<body onload="submit();">
<!-- PTC Recommended Customization(1) End -->
…
<!-- PTC Recommended Customization(2) Start -->
<script type="text/javascript">
/**
*Saves the URL fragment to session store, if it is available in browsers address bar
*/
function saveURLFragment() {
var URL_FRAGMENT_KEY = 'WINDCHILL_SSO_URL_FRAGMENT';
var windchillStore = window.sessionStorage;
if (windchillStore) {
var hash = document.location.href.split('#')[1];
if (hash && hash.length > 0) {
windchillStore.setItem(URL_FRAGMENT_KEY, hash);
} else {
// clean-up, if left by previous incomplete login attempt.
windchillStore.removeItem(URL_FRAGMENT_KEY);
}
}
}
function submit() {
saveURLFragment();
document.forms[0].submit();
}
</script>
<!-- PTC Recommended Customization(2) End -->
4. 修改以下文件以进行 Web 容器配置：
a. 编辑位于 $WT_HOME/codebase/WEB-INF 的 web.xml，在 MVCDispatcher <servelet-mapping> 中为 /sso/* URL 添加新条目，例如 /ptc1/* 和 /app/*。
例如，
<servlet-mapping>
<servlet-name>MVCDispatcherservlet-name>MVCDispatcher>
…
<url-pattern>/sso/*</url-pattern>
</servlet-mapping>
<servlet-name>MVCDispatcherservlet-name>MVCDispatcher>
…
<url-pattern>/sso/*</url-pattern>
</servlet-mapping>
b. 编辑位于 $WT_HOME/tomcat 的 config.xml，在 <target name="-addTargetedUriWorkerMapEntries"> 中为 /sso/* URL 添加新条目，例如 /ptc1/* 和 /app/*。
例如，
<target name="-addTargetedUriWorkerMapEntries">
…
<echo file="${uriworkerFile}" append="true" message="/${appName}/sso/*=${iisAjpWorker}${line.separator}">
</target>
…
<echo file="${uriworkerFile}" append="true" message="/${appName}/sso/*=${iisAjpWorker}${line.separator}">
</target>
5. 在服务器管理器中重新启动 Shibboleth Daemon 服务。
6. 配置 PTC HTTP Server。
PTC HTTP Server必须使用 Shibboleth 服务提供者模块进行配置。
 | 强烈建议为 PTC HTTP Server 配置 HTTPS。单一登录 (SSO) 解决方案无法取代 SSL 所提供的安全优势。有关详细信息，请参阅为 HTTP Server 和 Windchill 配置 HTTPS。 |
a. 启用 mod_shib 模块并配置初始选项
a. 将文件 <shibboleth_安装_目录>/etc/shibboleth/apache24.config 复制到 <http 服务器目录>/conf/conf.d/00-1mod_shib.conf。必须将文件命名为 00-1mod_shib.conf 以确保它是最先加载的模块之一。
b. 复制文件后，对其进行编辑，并将 ShibCompatValidUser 指令设置为 On。其默认值是 Off。
b. 禁用 Windchill 目录的默认身份验证规则，并保留匿名和备用身份验证前缀规则。
a. 在 Windchill shell 中，在 <http server directory> 中运行以下命令：
ant -DprotocolAuthOnly=true -f webAppConfig.xml regenAllWebApps
这将禁用 Windchill 中的默认身份验证规则。
c. 在 apache 配置中启用 SAML SSO 身份验证。
新建包含以下内容的文件 <http 服务器目录>/conf/conf.d/30-app-[WindchillWebAppName]-1Auth.conf：
<LocationMatch ^/+Windchill/+(;.*)?>
AuthType shibboleth
ShibRequestSetting requireSession 1
require shib-session
</LocationMatch>
AuthType shibboleth
ShibRequestSetting requireSession 1
require shib-session
</LocationMatch>
还需要为 Windchill 帮助中心和 PTC HTTP Server 上安装的任何其他 Web 应用程序启用 SAML SSO 身份验证。
对于 Windchill 帮助中心，新建包含以下内容的文件 <http 服务器目录>/conf/conf.d/30-app-[WindchillWHCWebAppName]-WHC-1Auth.conf：
<LocationMatch ^/+Windchill-WHC/+(;.*)?>
AuthType shibboleth
ShibRequestSetting requireSession 1
require shib-session
</LocationMatch>
AuthType shibboleth
ShibRequestSetting requireSession 1
require shib-session
</LocationMatch>
对于安装在 PTC HTTP Server 上的任何其他 Web 应用程序，请按照类似步骤进行操作。
d. 修改 <http_server_directory>/conf/conf.d/30-app-Windchill-AJP.conf 以便为 /sso/* URL 添加条目，就像 /ptc1 和 /app URL 的条目一样。
例如，
JkMount /Windchill/sso/* ajpWorker
7. 向标识提供者提供 Shibboleth 服务提供者元数据。
可通过必须提供给标识提供者的 URL 来访问 Shibboleth SP 元数据，以便将 Shibboleth 服务提供者注册到该提供者。按如下所示构建 URL：PTC_HTTP_Server_URL/Shibboleth.sso/Metadata。例如，如果 PTC HTTP Server URL 为 https://windchill.company.com ，则 Shibboleth 元数据 URL 为 https:windchill.company.com/Shibboleth.sso/Metadata。
Shibboleth 服务提供者故障排除和调试
Shibboleth Daemon 日志文件位 <shibboleth_install>/var/log/shibboleth。在 Linux 上，需要具有 root 访问权限才能读取这些日志文件。如果要切换到其他位置：HTTP Server、Shibboleth 模块日志文件位于 <install_directory>/var/log/shibboleth-www 中。在 Linux 上，非 root 用户没有此目录的写入权。如果不尝试在端口 80 上运行 Web 服务器，则 PTC HTTP Server 通常作为非 root 用户运行。此时，不会创建日志文件。可通过修改 /etc/shibboleth/native.log 来更改日志文件的位置。将以下两个特性更改到可写入位置：
log4j.appender.native_log.fileName=/var/log/shibboleth-www/native.log
log4j.appender.warn_log.fileName=/var/log/shibboleth-www/native_warn.log
例如，您可以创建以下目录 /opt/ptc/logs 并将特性设置为使用该目录中的日志文件。
要启用调试日志记录：
编辑 /etc/shibboleth/native.loggger 并将 rootCategory loglevel 更改为 DEBUG。(log4j.rootCategory=INFO, native_log, warn_log 变为 log4j.rootCategory=DEBUG, native_log, warn_log)。这将极大地提高 Shibboleth Daemon 和 Shibboleth 模块以及 /var/log/shibboleth-www 或放置这些文件的位置上的原生文件的详细程度。
重新启动 Shibboleth 服务提供者和 PTC HTTP Server
Shibboleth 服务提供者包含两个组件：Shibboleth Daemon 和 PTC HTTP Server 中的模块。重新启动这两者中任意一个时，这两个服务都需要重新启动。在 Windows 上，Shibboleth Daemon 将配置为 Windows 服务，可通过服务控制面板重新启动。在 Linux 上，它是 shibd.service systemd 单元，可以使用 systemctl 停止和启动。有关启动和停止 PTC HTTP Server 的详细信息，请参阅启动 HTTP Server 和 Windchill 方法服务器。
客户端兼容性
Creo Parametric 和 Windchill Workgroup Manager 的嵌入式浏览器无法使用主浏览器中 Windchill 会话中的登录缓存。因此，无法完全创建单一登录体验，因为用户可能会看到 Creo Parametric 和 Windchill Workgroup Manager 的嵌入式浏览器中的额外登录请求。嵌入式浏览器将使用在 SAML 配置中指定的标识提供者对用户进行身份验证。
如果 Arbortext Editor 是 PTC 解决方案的一部分，则在站点上配置 SAML 时需要考虑其他一些事项。有关详细信息，请参阅支持文章 CS250036。
不支持配置某些客户端进行 SAML 身份验证。在您的站点上实施 SAML 身份验证之前，应检查这些客户端在您的站点中的使用范围，以及这些客户端排除项目对于使用 SAML 身份验证是否有障碍。PTC 不支持以下客户端的 SAML 身份验证配置：
• Windchill Gateway for Creo Elements/Direct Model Manager
有关客户端与 SAML 身份验证兼容性的最新信息，请参阅支持文章 CS250038。
将 PingFederate 配置为标识提供者
以下步骤将提供有关配置 PingFederate 与 Windchill 服务器上的 Shibboleth SP 安装之间连接的指南。这是一个可选配置，不是在 Windchill 中启用 SAML 身份验证的必要配置。您可以选择在 SAML 部署中使用不同的 IdP，具体取决于企业 SSO 联合的要求。有关下载受支持的 PingFederate 版本和获取许可证的详细信息，请参阅单一登录身份验证。
这些步骤对前面 SAML 配置主题中所提供的说明进行了补充，并假定已安装 PingFederate 和 Shibboleth 服务提供者。将 PingFederate 作为 IdP 和 Shibboleth 服务提供者的配置步骤相互独立，因此您需要更新每个客户端的配置以导入从其他客户端导出的元数据 XML 文件。
1. 在 PingFederate 中，创建服务提供者连接。
a. 有关创建服务提供者连接的说明，请参阅 PingFederate 产品文档。在 PingFederate 管理控制台中，导航至 > ，然后单击 Create New.
b. 导入您在 Windchill 服务器上安装 Shibboleth 服务提供者客户端时导出的 metadata.xml 文件。有关检索此文件的说明，请参阅 SAML 身份验证配置主题中的第 6 步。
2. 确认已将 PingFederate 配置为将用户身份验证重定向到您的企业目录服务器 (LDAP 或 ADFS)。请参阅 PingFederate 和目录服务器中的产品文档，并与您的目录服务器管理员进行协调以配置 PingFederate。
3. 在 PingFederate 中，导出您所创建的 SP 连接的元数据 XML 文件，如有必要，将其重命名为 idp-metadata.xml。
4. 在 Windchill 服务器上的 Shibboleth 服务提供者安装程序中，执行以下配置。
a. 导入从 PingFederate SP 连接导出的 idp-metadata.xml 文件，方法是将其保存到 Shibboleth SP 安装目录中。将以下标记添加到 shibboleth2.xml 文件，对其进行修改以反映 idp-metadata.xml 文件的保存位置。
<MetadataProvider type="XML" validate="true" file="location to metadata xml file>"/>
b. 将 SSO entityID 配置为与您在 PingFederate 中创建的 SP 连接的 entityID 相匹配。这可从您在 PingFederate 中导出的 idp-metadata.xml 文件内检索到。
5. 重新启动 Apache Tomcat、Shibboleth SP 和 Windchill Server。登录到 Windchill，确认登录 URL 重定向到 PingFederate 登录页面且您已成功登录。
| | 配置 SSO 身份验证时，登录尝试次数由您的标识提供者确定。请联系您的 IdP 管理员，以了解当前目录服务器的登录尝试策略。如果您先前已经为 Windchill 目录服务器或其他 LDAP IdP 中的无效登录尝试配置用户帐户锁定设置，则应审阅在新 IdP 中设置的策略，以确保其符合您的安全要求。 |
将 Azure Active Directory 配置为标识提供者
1. 在 Microsoft Azure 门户中使用 Integrate any other application you don't find in the gallery (Non-gallery) 选项创建新的企业应用程序。有关创建企业应用程序的详细信息，请参阅 Microsoft Azure 文档。
2. 浏览到 > > 。
3. 通过提供下述各部分的详细信息，使用 SAML 设置单一登录：
a. 基本 SAML 配置：
▪ 上载元数据文件 - 将 Metadata.xml 文件从 Shibboleth (服务提供者) 下载到任何方便的位置。单击 Upload metadata file，然后从其所在位置选择 Metadata.xml。
▪ 手动输入详细信息 - 单击 Edit，并定义身份验证所需的所列全部 URL 的值，并在 Basic SAML Configuration 下对其重新进行身份验证。要定义的 URL 包括 Entity ID、Reply URL、Sign on URL、Relay State 和 Logout URL。请注意，Entity ID 是 Metadata.xml 或 shibboleth2.xml 中提供的服务提供者实体。
b. 用户属性和声明：
a. 单击 Edit，为 Azure Active Directory 应用程序提供声明值/名称并进行更新。
b. 浏览至 Manage claim。将 Name 更新为 user.userprincipalname 声明值的 uid。
c. SAML 签名证书：
a. 单击 Federation Metadata XML 前面的 Download 链接，下载 IDP 元数据文件。将 idp-metadata.xml 文件替换为位于 \opt\shibboleth-sp\etc\shibboleth\ 位置的已下载 IDP 元数据文件。