01
访问管理架构
在设计访问管理架构的时候，
通常会有如下2种模式。
Workspace ONE Access 采取的是下面第2种模式。
1
第一种验证可以是实时的。
每当用户发起访问时，Access 会即可向目录查询。
优点
你可以查询到实时的用户信息， 而且只存在1个用户对象。 缺点
目录服务器负载加重。
如果速度不理想或和目录服务器断开连接，
会导致流程中断。
2
第二种是定期做用户对象同步。
A
ccess 会保存一份用户对象。
优点
自有用户资料库，
不用受限于到目录服务的网络情况。
即使和目录服务器中断连接也没有影响。
缺点
定期同步复制，并非实时。
存在多个用户对象。
02
用户资料库
Workspace ONE Access 里存放的用户对象可能多种多样：
从 AD、LDAP、OKTA 同步而来；
管理界面上可以自建；
Workspace ONE UEM 用户预置；
透过API写入用户对象；
第三方 IDP 写入即时(JIT)用户...
目录是多种多样，数量上没有限制。
但是要确保每个用户对象都是唯一的。
无非是：
1 对象有唯一属性
2 对象位于不同目录。
可以创建本地目录 ，
从各个目录中同步用户对象，
同时配置不同的规则来筛选所需的用户。
利用好这些规则创建动态组，可以让你非常轻松的进行授权。
本地用户可以设定密码策略。
如果是从 AD 同步的用户对象，密码策略由 AD 来设定。
03
用户属性
点开某个用户，你会看到常见的不少用户属性。
当然你还可以通过添加获取更多用户属性。
如果创建了新的用户属性，
需要 map(对应)到用户属性上。
这样可以在 SAML 认证过程中使用新的用户属性。
我们通过一个实际例子来看一下
比如 AD 里面的用户对象
有一个叫做 “description” 的属性，
注意是全小写的。
1. 接下来，
我们到 Access 中
找到这个用户。
此时看不到这个属性。
2. 我们首先要确认是否已经同步了该属性。
从下图我们可以看到这里自定义了属性。
但属性名称为“Description”，首字母 D 大写了。
3. 接下来我们点开同步属性，
确认属性是否得到正确对应。
这里我们可以看到
Description 对应了 AD 的 “description” 属性，
应该没有问题。
那么我们如何能查看所有属性？
4. 我们要把访问地址中的
/admin/userGroups?patch=/users/
替换为/jersey/manager/api/scim/Users/
回车后我们就可以看到所有属性。
Firefox这里的显示JSON比较好，
可以从末端找到我们需要的Description属性。
可以看到用户属性已经被正确同步了。
如果浏览器对JSON支持不好，
可以点击raw data里面的pretty print，
显示会更加友好一些。
5. 最后，我们来看看本地的动态用户组。
6. SFDC Admin Users 就是我们的本地动态用户组。
点开后我们可以手工添加用户。
但更好的方式是使用用户过滤规则。
也可以在过滤规则的基础上再次排除自己不需要的用户。
这样我们动态组目前的用户从12名下降到6名。
7. 我们可以手工把 Bjork,Peter 加进来。
8. 下面我们再试着排除Admin,test。
点击➕就可以将该用户加入排除列表中。
刷新后可以看到该用户从组中消失了。
这种组规则非常灵活，可以根据需求进行调整。
大家可以多进行尝试。
