[outsystems学习]用户管理2

■最终用户认证

*`仅限于OUt systems程序用户的最终用户认证。开发者，IT管理者在Lifttime构成认证。

*最终用户认证的6种方式：

1）内部情報（Internal）：缺省方式，Hash函数加密

2）Active Directory：仅限on-premises

3）LDAP：

4）SAML2.0

5）Azure AD

6）Okta

*补充：

A）最终用户认证的6种方式中，Internal以外不需要手动作成用户，最初Login时自动在Outsystems数据库里作成，但不保存密码。

B）Active Directory或LDAP认证时，Outsystems数据库里有用户和密码时会优先最初使用本地认证,而SAML 2.0、Azure AD、Okta的认证不会这样。

C）不能对同一用户设定两种认证方式，Outsystems程序的最终用户需要在同一IdP构成的认证。但是，使用独自用户提供者（User Provider）时例外。

■认证流程

最终用户最初使用只有认证过用户可表示的程序画面时，发生安全例外。

1.SAML 2.0、Azure AD、Okta的构成平台时，最终用户重定向到企业资格认证（用户名和密码）Web页面，成功后回到原来的Outsystems程序页面。

2.统合Windows认证平台并且最终用户在Platform Server·同一个域时，使用统合Windows认证：

 最终用户页面请求后，服务器返回HTTP 401（未认证）状态，通知浏览器需要认证。

   1）若浏览器里保有最终用户的资格信息，则会自动送往Web服务器进行认证。

   2）若没有保存，资格信息录入表在浏览器里表示,输入内容送往服务器。定制的Login画面不会表示给最终用户。

3.平台没有统合Windows认证时，重定向到Login画面，最终用户资格信息送信时进行以下处理：

   1）照合Outsystems数据库验证资格信息

   2）进行平台是否用Active Directory或LDAP认证确认

         A）平台用Active Directory时，照合域服务器验证

         B）平台用LDAP时，照合LDAP服务器验证

4.以上最终用户认证不成功时「 Invalid Login 」表示

■用户数据同期

Active Directory、LDAP、SAML 2.0、Azure AD、Okta方式最终用户认证1回或复数回后，OutsystemsDB用户表的下述字段数据被更新：

• 用户名称
• Email
• Mobile Phone

#认证的同期时间点： 

• Login成功后，Active Directory、LDAP、SAML 2.0、Azure AD、Okta方式时，Login用户数据更新
• 设置日次计时器时，外部认证source里所有既存用户的数据更新， 对象用户名包含¥　　　　
• 计时器名「SynchronizeDomainUsers」

#既知问题：

在Active Directory对用户做无效化处理后，由SynchronizeDomainUsers更新同期。

但是在Active Directory对用户做有效化处理后，Users表没被更新。

 #永续Login：

  *设定：User_Login Action 的RememberLogin属性：［True］

  *旧Web：10天，React Web：30天

 *旧Web的设定：Forge-》Factory Configuration-》［Platform Configurations］TAB-》Remember Login(days)的参数变更

 *React Web：Service Center侧永续认证的Max Idle Time参数变更