5 分钟部署一个 OAuth2 服务并对接 Shibboleth-IdP 3.4.6
前言
这还是一个标题党。
OAuth2 现在已经是开放授权协议的事实标准，你可以看到几乎所有的 xxx 开放平台均采取的 OAuth2 协议来进行授权。而在 Authorization Code 模式的基础上结合 JWT ，标准化的 userinfo endpoint 和服务发现，就成了 OpenID-Connect。当然即便不加上这些限定，OAuth2 在 Authorization Code 模式下，也通常被用作统一身份认证的解决方案提供给用户。而由于 OAuth2 与 CAS 不同，缺乏 Apereo CAS 这样的重量级产品来对标（话说回来，Apereo CAS 现在自己就支持 OAuth2 来着）。于是市场上的 OAuth2 实现可谓群魔乱舞，槽点一时难以穷尽。
个人建议，在选取 OAuth2 产品时，务必通过 进行测试，以验证协议实现的标准性，避免将来踩坑。而如果需要自己临时起一个 OAuth2 服务做测试的话嘛~~~
是的，搭一个 OAuth 服务器 5 分钟就够了。
Apereo CAS - OAuth2
是的，Apereo CAS 现在也支持 OAuth2 协议了，所以如果你已经按照 的路程部署好了 CAS 服务的话，那么只需要略微的调整，就可以让他支持 OAuth2 了，5 分钟足矣。
下文假定已经安装好了 shibboleth-idp-3.4.6 和 cas 6.1 ，并使用 httpd 方式代理发布。
dependencies {
// Other CAS dependencies/modules may be listed here...
compile "org.apereo.cas:cas-server-support-json-service-registry:${casServerVersion}"
compile "org.apereo.cas:cas-server-support-ldap:${casServerVersion}"
compile "org.apereo.cas:cas-server-support-oauth-webflow:${project.'cas.version'}"
}
{
@class : org.apereo.cas.support.oauth.services.OAuthRegisteredService
clientId: google
clientSecret: google
serviceId: ^https://developers.google.com/.*
name: OAuthService
id: 1000
supportedGrantTypes: [ "java.util.HashSet", [ "authorization_code" ] ]
supportedResponseTypes: [ "java.util.HashSet", [ "code" ] ]
}
设置好 ，，设置好允许的 ,也就是 。
cas.authn.oauth.userProfileViewType=FLAT
此处默认的值是 ，此时 的中，属性部分是带 的子结构的, 如果是 的话，则会去掉结构铺平。以下示例引用自
# Nested
{
"id": "casuser",
"attributes": {
"email": "casuser@example.org",
"name": "CAS"
},
"something": "else"
}
# FLAT
{
"id": "casuser",
"email": "casuser@example.org",
"name": "CAS",
"something": "else"
}
Shibboleth-IdP 的 OAuth2 对接需要去掉结构，所以我们使用 模式
好啦，重新编译 并运行，OAuth2 服务已经搞定了，去 测试一下吧。
Endpoints
Authorization endpoint :
Token endpoint :
Userinfo endpoint :
oauth-server-lite
如果没有 CAS 部署的前序工作的话，5 分钟的时间可能不太够。但是既然 已经立好了。。。我们可以用 来快速的构建一个 服务。
$ yum install epel-release
$ yum install redis
$ systemctl start redis
$ systemctl enable redis
$ mkdir oauth-server-lite
$ cd oauth-server-lite
$ wget https://github.com/shanghai-edu/oauth-server-lite/releases/download/v0.3.0/oauth-server-lite-0.3.tar.gz
$ tar -zxvf oauth-server-lite-0.3.tar.gz
$ mv cfg.example.json cfg.json
{
"log_level": "info", # info/warn/debug 三种
"db": {
"sqlite":"sqlite.db", # 只要不为空，则使用 sqlite 模式，存储到字段中的 sqlite 文件中
"mysql": "root:password@tcp(127.0.0.1:3306)/oauth?charset=utf8&parseTime=True&loc=Local", # 使用 mysql 模式时的数据库连接参数
"db_debug": false # true 时会输出详细的 sql debug
},
"redis": {
"dsn": "127.0.0.1:6379",
"max_idle": 5,
"conn_timeout": 5, # 单位都是秒
"read_timeout": 5,
"write_timeout": 5,
"password": ""
},
"redis_namespace":{ # redis key 的命名空间，保持默认即可
"oauth":"oauth:",
"cache":"cache:",
"lock":"lock:",
"fail":"fail:"
},
"ldap": {
"addr": "ldap.example.org:389",
"baseDn": "dc=example,dc=org",
"bindDn": "cn=manager,dc=example,dc=org",
"bindPass": "password",
"authFilter": "(&(uid=%s))",
"attributes": ["uid", "cn", "mail"], # ldap 返回的属性。这部分会映射为 userinfo 的接口。如果留空则返回全部属性
"tls": false,
"startTLS": false
},
"http": {
"listen": "0.0.0.0:18080",
"manage_ip": ["127.0.0.1"], # 管理接口的授信 ip
"x-api-key": "shanghai-edu", # 管理接口的 api key
"session_options":{ # session 参数
"path":"/",
"domain":"idp.example.org", # 必须与实际域名匹配
"max_age":7200,
"secure":false,
"http_only":false
},
"max_multipart_memory":100
},
"max_failed":5, # 最大密码错误次数
"failed_intervel":300, # 密码错误统计的间隔时间
"lock_time":600, # 锁定时间
"access_token_expired":7200, # oauth access token 有效期，单位是秒
"old_access_token_expired":300, # 新的 oauth access token 生成时，老 token 的保留时间
"refresh_token_expired_day":365, # refresh token 的有效期，单位是天
"code_expired":300 # authorization_code 的有效期，单位是秒
}
配置文件的示例。考虑到 5 分钟还是有点紧张，我们只挑重要的部分修改。把 部分的配置修改为实际的 参数，把 修改为实际的服务器域名。然后执行 运行
ProxyPreserveHost On
RequestHeader set X-Forwarded-Proto https
RemoteIPHeader X-Forwarded-For
ProxyPass "/resource/" "http://localhost:18080/resource/"
ProxyPass "/oauth/" "http://localhost:18080/oauth/"
ProxyPass "/user/" "http://localhost:18080/user/"
$ curl -H "X-API-KEY: shanghai-edu" -H "Content-Type: application/json" -d "{\"grant_type\":\"authorization_code\",\"domain\":\"developers.google.com\"}" http://127.0.0.1:18080/manage/v1/client
{"client_id":"8455e95a63d682bb","client_secret":"385a8174dd0799e220a8407f8ca6e8a9","grant_type":"authorization_code","domain":"developers.google.com","white_ip":"","scope":"Basic","description":""}
endpoints
Authorization endpoint :
Token endpoint :
Userinfo endpoint :
对接 Shibboleth-IdP 3.4.6
其实 3.4.6 之后，由于新版插件均采用标准的 模式运行，因此 IdP 的 OAuth2 对接和 CAS 对接基本是完全一致的 —— 实际上 插件本来就是在 插件的基础上改的。有变化的地方仅 2 处。
参考文献
以上
行文有微调。