微观天下

发表于 分类于 ，

Authentication服务鉴权机制

用户在访问系统或者服务时，服务器端需要验证用户是否拥有访问的权力，这个过程称为鉴权。在服务器-客户端架构的软件系统中，当一个没有经过鉴权的用户登录时，服务器可能会返回鉴权请求。鉴权是一种客户端和服务器协同认证的方式，有多种方式可以实现：

  • HTTP Basic Authentication
  • session-cookie
  • Token 验证(JWT)
  • OAuth(开放授权)

HTTP Basic Authentication

HTTP认证时一种无状态的认证模式，因此用户在提供相关凭据的请求中能够得到认证用户的访问，而服务器本身在接下来的请求中并不能持续保持登录状态。

HTTP基本认证的具体流程如下:

在你访问一个需要HTTP Basic Authentication的URL的时候，如果你没有提供用户名和密码，服务器就会返回401，返回Header中会包含类似”WWW-Authenticate: Basic realm=”test””信息。如果你直接在浏览器中打开，浏览器会弹出对话框提示你输入用户名和密码。

要在发送请求的时候添加HTTP Basic Authentication认证信息到请求中，有两种方法:

  1. 在请求头中添加Authorization信息：Authorization: “Basic {用户名:密码}的base64加密字符串”。
  2. 在url中添加用户名和密码。

其中，鉴权机制中的身份验证并非一定要依赖Basic方式的用户名密码作为凭据，可以通过如下方式：

  1. “WWW-Authenticate: Negotiate” SPNEGO协议,支持Kerberos, NTLM点对点认证方式完成。在协商过程中：

    • 可以请求 Authorization: Negotiate {kerberos票据}进行Kerberos验证
    • 或者也能读取返回头中的 Authorization: Negotiate NTLMSSP{八字节质询码} ，并在请求头部中加入 Authorization: Negotiate NTLM{加密的质询码和明码用户名}

  2. “WWW-Authenticate: Digest realm=”test”,qop=”auth”,nonce=”{md5加密时间},opaque=”{不透明字符串}”摘要认证协议，能避免明文传输数据。

    • 在请求中需要加入 Authoriztion: Digest username=”guest”,realm=”test”,nonce=”{同上},qop=”auth”,nc=”00000001”,response=”{通过md5加密的user paswd httpmethod uri等信息}”,cnonce=”{客户端提供的非明文字符串}”,uri=”{uri信息}”
    • 服务器需要检查时间在允许范围内，而且response匹配本地生成值。使用MD5算法的优势在于可以很快正向哈希，而无法短时间内逆向哈希得出用户密码等信息。

session-cookie鉴权

Session是HTTP协议中为了支持有状态的通信而发明的会话机制，本质上是通过服务器为用户建立sessionid从而保证用户的状态信息能够在服务器端保存。用户不需要反复进行登录认证就能保持会话。

而Cookie则是一种特殊的HTTP头部，能够在HTTP通信中保存一定的用户信息，如sessionid从而达到认证用户的目的。由于Cookie本身是针对某一域名而产生的，所以在发送Cookie过程中必须提供正确域名的sessionid才行。

具体流程如下：

cookieAuth

Cookie鉴权常用Single Sign On场景，例如，于对于企业中的不同子域名的验证，可以通过结合SAML, CAS等协议完成。对于不同网络更加广泛的第三方验证则有OIDC协议支持。

Token 验证(JWT)

Token验证方式和Seesion验证方式很类似，不同的是Token本身包含一些有意义的信息：用户名、密码、过期时间等。Token本身由服务器签发，客户端请求的发送中需要包含 Authorization : JWT “{jwt token}”，服务器提取token信息通过相同的算法验证即可。相较于Session验证方式节约了分布式系统中服务器存储sessionid和用户信息的开销，只需要服务器拥有相同的密钥即可。

具体流程如下:

tokenAuth

JWT(json-web-token)算法细节：

JWT由三部分”{header}.{payload}.{signature}’,两种算法生成，公式如下：
signature = sha256(base64(header)+’.’+base64(payload),{服务器密钥})

  1. header包含算法和类别信息,
  2. payload为加密部分，包含公有声明和私有声明，公有声明为约定的key，私有为公司定制key，
  3. signature，算法签名。
  4. sha256为header中写的加密算法，基于服务器密钥生成不同的加密签名,具有不可逆性
  5. base64为编码算法，可逆运算

OAuth2/OIDC认证

OIDC 即Open ID Connect, 是一种基于OAuth2授权流程，并且扩展了身份认证层的一种新的认证机制。

OIDC认证模型主要包含如下四个角色和一个令牌（完整术语参见http://openid.net/specs/openid-connect-core-1_0.html#Terminology）：

  • EU用户：End User：一个人类用户。
  • RP客户端：Relying Party ,用来代指OAuth2中的受信任的客户端，身份认证和授权信息的消费方；
  • OP认证服务器：OpenID Provider，有能力提供EU认证的服务（比如OAuth2中的授权服务），用来为RP提供EU的ID Token身份认证信息和Access Token访问令牌；
  • UE用户资源服务器：UserInfo Endpoint用户信息接口（受OAuth2保护），当RP使用Access Token访问时，返回授权用户的信息，此接口必须使用HTTPS。
  • ID Token认证令牌：JWT格式的数据，包含EU身份认证的信息。通过OP提供。

认证流程如下：

OIDCAuth

其中，UserIndo EndPoint是一个受OAuth2保护的资源。在RP得到Access Token后可以请求此资源，然后获得一组EU相关的Claims，这些信息可以说是ID Token的扩展，比如如果你觉得ID Token中只需包含EU的唯一标识sub即可（避免ID Token过于庞大），然后通过此接口获取完整的EU的信息。此资源必须部署在TLS之上。

OIDC的支持的授权流程如下：

  1. Authorization Code(授权码模式)：使用OAuth2的授权码来换取Id Token和Access Token。
  2. Implicit (简化模式)：使用OAuth2的Implicit流程获取Id Token和Access Token。
  3. Hybrid(混合模式)：混合Authorization Code +Implicit。

OAuth2授权模型

OAuth2的授权模型时为了已登录用户通过第三方应用访问资源服务器进行授权的流程，授权模型和OIDC相似，包含如下四个角色:

  • 资源拥有者（User） - 指应用的用户，比如github的一个账户拥有者
  • 认证服务器 （Authorization Server） - 提供登录认证接口的服务器，比如：github等
  • 资源服务器 （Resources Server） - 提供资源接口及服务的服务器，通常和认证服务器是同 一个应用。
  • 第三方客户端（Client） - 第三方应用，希望使用资源服务器提供的资源，比如你的一个支持通过github账户登录的应用
  • 服务提供商(Provider): 认证服务和资源服务归属于一个机构，该机构就是服务提供商，比如github公司

OAuth2具有四种授权模式，下文将分述这四种模式具体流程：

  • 授权码模式（authorization code）
  • 简化模式（implicit）
  • 密码模式（resource owner password credentials）
  • 客户端模式（client credentials）

授权码模式(最为常见)

  1. 用户访问客户端应用
  2. 引导用户到认证服务器进行登录（此步骤需要携带客户端应用的clientId，可以是html直接转发认证服务器），用户输入用户名、密码
  3. 认证成功后，认证服务器向客户端应用发一个授权码code
  4. 客户端应用拿着授权码code，和clientId，clientSecret，去换取access_token
  5. 返回access_token给客户端应用

AuthorizationCodeOAuth

这种场景下，用户名、密码、客户端应用信息，都没有直接暴露在浏览器，是web下是最安全的。

简化模式

授权码模式的简化，用户认证成功后，直接将token返回给浏览器。因为某些应用没有前端服务器，只有一堆静态的html（很少见），这种模式，一般不用。

ImplicitOAuth

密码模式

适用场景：手机app ，这个客户端应用是你完全可以信任的，你的app就是自己公司开发的。但是这个模式并不适合在web场景下用，在web下，用户名密码并不是直接填给自己写的应用的，而是填在浏览器呈现的一个页面上的，这个浏览器是客户端应用的一个代理，浏览器是没法保证安全性的。

PasswordOAuth

客户端证书模式

客户端应用直接发 clientId、clientSecret给认证服务器，发的令牌是针对客户端应用的，不是针对用户的。跟没授权一样，令牌不能识别用户身份。

ClientOAuth

Authentication实战

本章将着重描述如何在java springboot应用中实现相应的认证流程。springboot提供了一站式应用的开发模式，但是认证流程是需要spring security，同时具体的认证核心模块需要spring securty keberos或者spring security oauth组件支持。下文将主要介绍如何利用这两个模块实现具体的基于siteminder/spnego/oauth协议的认证流程。

siteminder sso + preauth

Siteminder是企业级认证产品，它提供了一站式认证中间件，从应用开发者的角度来看，就是采用了外部认证系统，应用不需要重新进行认证而是可以直接从siteminder处理过的http request header中提取SM_USER中拿到userprincipal()。因此从spring securty框架的角度之需要直接读取认证后的信息，而不需要再对request进行认证验证。这通常是一种企业内网用户认证采用的sso机制，因为用户之需要进行简单认证后就能得到对多种内部webapp的访问toekn，而且不需要进行细粒度的鉴权的场景适合大部分内部应用，但是，因为外部网站可容易会被假的header所欺骗，安全性较差而不会采用这种方式进行验证。

spnego auth

SPNEGO是微软设计的一种企业级认证协议，底层支持多种token协议，因此是应用proid常用的一种方式，因为应用的id会常常跑在不同的window/linux环境，而spnego能够支持多种密钥认证从而对跨系统认证能有很好的支持，这种认证方式需要用户自己执行认证检查，所以需要spring-security-keberos模块的相关auth provider进行验证。

oidc oauth2 + ping federate

oauth标准的实现一般是用oidc协议，spring security oauth2拥有对oauth2标准的鉴权模型的实现，并且可以通过适当的配置完成oidc用户验证。oauth单独并不能完成验证鉴权功能，需要部署一个oauth provider例如云服务商azure AD等，企业级内部可以自己部署ping federate服务器完成auth信息提供功能，并且向下兼容sso（即open Id）功能。

Ping Identity是支持OIDC和OAuth2标准的企业化产品

以https://abc.com作为签发域名，PingIdentity具体支持方式如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
{
  "issuer": "https://abc.com", // 
  "authorization_endpoint": "https://abc.com/as/authorization.oauth2",
  "token_endpoint": "https://abc.com/as/token.oauth2",
  "revocation_endpoint": "https://abc.com/idp/userinfo.openid",
  "introspection_endpoint": "https://abc.com/as/inrospect.oauth2",
  "jwks_uri": "https://abc.com/pf/JWKS",
  "outh_jwks_uri": "https://abc.ocm/ext/oauth/JWKS",
  
  "scopes_supported" : [
    "address",
    "phone",
    "openid",
    "profile",
    "email"
  ],
  "claims_supported": [
    "email",
    "email_verified",
    "family_name",
    "given_name",
    "name",
    "preferred_username",
    "sub"
  ],
  "grant_types_supported": [
    "implicit",
    "authorization_code",
    "refresh_token",
    "password",
    "client_credentials"
  ]
}
  • authorization_code 授权码流程
  1. 用户发起请求到授权码endpoint：

打开chrome.exe，发起 GET https://abc.com/as/authorization.oauth2?client_id=foo&response_type=code&redirect=https%3A%2F%2Fabc.com%2Freal%2Fdocs%2F&scope=openid 请求

Chrome界面 redirect to url: https://abc.com/real/docs/?code=XXXXXXXXXXXXXXXXXX 获得授权码。

  1. 用户用返回授权码发起token请求：
1
2
curl -k --data "grant_type=authorization_code" --data "client_id=foo" --data "code=xxxxxxx" --data "redirect_uri=https://abc.com/real/docs/" https://abc.com/as/token.oauth2

返回token json:

1
2
3
4
5
6
7
{
  "id_token" : "xxxxxxxxxxxxxxxxx",
  "access_token" : "xxxxxxxxxxxxxx",
  "refresh_token": "xxxxxxxxxxxxxxxxxx",
  "token_type": "Bearer",
  "expires_in": 7200
}
  1. 用户刷新过期token请求：
1
2
curl -k --data "grant_type=refresh_token" --data "client_id=foo" --data "refresh_token=XXXXXXXXXX" --data "redirect_uri=https://abc.com/real/docs/" https://abc.com/as/token.oauth2

  • JWT 验证流程：

  1. 对于RSA加密算法加密的token，需要公私钥才能进行加解密。 “jwks_uri”: “https://abc.com/pf/JWKS“, 认证服务器会用私钥将内容加密并且作为jwt的签名部分签发给客户端，资源服务器拿到jwt token后，需要用公钥解密签名，并且和明文的payload的进行比较确认没有篡改则为有效。整个算法过程有已有的实现例如jose4j。

  2. 对于对称加密算法的token，假设资源服务器和认证服务器都已经知道密钥内容，客户端拿到jwt token后，资源服务器需要利用密钥进行解密，并且验证payload的合法性即可。

Jetty Session Model

发表于 更新于 分类于 ，

窗口消息

GUI应用程序必须响应来自用户和操作系统的事件。

来自用户的事件包括用户与程序交互的所有方式：鼠标点击、按键、触摸屏手势等等。
来自操作系统的事件包括程序之外的任何可能影响程序行为的东西。例如，用户可能插入一个新的硬件设备，或者Windows可能进入低功耗状态(睡眠或休眠)。
这些事件可以在程序运行时的任何时间发生，几乎可以按任何顺序发生。如何构造一个不能预先预测执行流（flow）的程序?

为了解决这个问题，Windows使用了消息传递模型。操作系统通过传递消息与应用程序窗口进行通信。消息只是指定特定事件的数字代码。例如，如果用户按下鼠标左键，窗口将接收到具有以下消息代码的消息。

C++

#define WM_LBUTTONDOWN 0x0201

一些消息具有与它们相关联的数据。例如，WM_LBUTTONDOWN消息包含鼠标光标的x坐标和y坐标。

要将消息传递给窗口，操作系统将调用为该窗口注册的窗口过程。(现在你知道窗口程序的作用了。)

https://learn.microsoft.com/zh-cn/windows/win32/learnwin32/your-first-windows-program

窗口句柄

窗口句柄是消息传递的源和目的，在每一个进程空间窗口句柄都是局部的，需要通过窗口名字去发现，对于某个窗口消息队列的监测，可以通过visual studio自带的spy++去定位监听并且调试。

发表于 更新于 分类于 ，

Az Setup for a oc cluster in single node

Az Login

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
PS C:\Users\loginid> az login
A web browser has been opened at https://login.microsoftonline.com/organizations/oauth2/v2.0/authorize. Please continue the login in the web browser. If no web browser is available or if the web browser fails to open, use device code flow with `az login --use-device-code`.
[
  {
    "cloudName": "AzureCloud",
    "homeTenantId": "85cb24e4-0bcf-4767-b44b-39eae544706e",
    "id": "bd435e85-b401-48c5-90ad-96dbefac1503",
    "isDefault": true,
    "managedByTenants": [],
    "name": "Visual Studio Professional",
    "state": "Enabled",
    "tenantId": "85cb24e4-0bcf-4767-b44b-39eae544706e",
    "user": {
      "name": "sunny_hll@hotmail.com",
      "type": "user"
    }
  }
]

Az Terraform example

1
2
3
4
5
6
7
8
9
10
11
12
13
14
PS C:\Users\loginid> az ad sp create-for-rbac --role="Contributor" --scopes="/subscriptions/bd435e85-b401-48c5-90ad-96dbefac1503"
Creating 'Contributor' role assignment under scope '/subscriptions/bd435e85-b401-48c5-90ad-96dbefac1503'
The output includes credentials that you must protect. Be sure that you do not include these credentials in your code or check the credentials into your source control. For more information, see https://aka.ms/azadsp-cli
{
  "appId": "414b5739-2c30-4cea-adff-d5c8ff1c6470",
  "displayName": "azure-cli-2022-12-09-06-36-24",
  "password": "if48Q~Wd6aUHekpKNLrgJWeC3Pr-sstzZHRXfa90",
  "tenant": "85cb24e4-0bcf-4767-b44b-39eae544706e"
}

PS C:\Users\loginid> $Env:ARM_CLIENT_ID = "414b5739-2c30-4cea-adff-d5c8ff1c6470"
PS C:\Users\loginid> $Env:ARM_CLIENT_SECRET = "if48Q~Wd6aUHekpKNLrgJWeC3Pr-sstzZHRXfa90"
PS C:\Users\loginid> $Env:ARM_SUBSCRIPTION_ID = "bd435e85-b401-48c5-90ad-96dbefac1503"
PS C:\Users\loginid> $Env:ARM_TENANT_ID = "85cb24e4-0bcf-4767-b44b-39eae544706e"

Az 手动创建VM

查询VM配置的地区Spot资源不太可用

1
az vm list-skus --location centralus --resource-type virtualMachines --zone --all --output table

VM Login

1
ssh -i ~/.ssh/oc_key.pem loginid@20.100.44.77

Az 部署oc

CRC setup guide: https://crc.dev/crc/getting_started/getting_started/using/

Maybe install for ubuntu OS:

1
2
3
sudo apt install gnome-keyring
sudo apt install dbus-x11
sudo snap install kubectl --classic

下载CRC

1
2
wget https://developers.redhat.com/content-gateway/rest/mirror/pub/openshift-v4/clients/crc/latest/crc-linux-amd64.tar.xz -o /var/tmp/crc-linux-amd64.tar.xz

VPN env network setting:

https://github.com/crc-org/crc/wiki/VPN-support--with-an--userland-network-stack

!!reset Disk size t0 128G as crcbundle took more than 30G space.

启动CRC

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
Started the OpenShift cluster.

The server is accessible via web console at:        
  https://console-openshift-console.apps-crc.testing

Log in as administrator:
  Username: kubeadmin
  Password: i4GM8-VqA42-8Eqix-pAg7h

Log in as user:
  Username: developer
  Password: developer

Use the 'oc' command line interface:
  $ eval $(crc oc-env)
  $ oc login -u developer https://api.crc.testing:6443

创建oc hello项目

环境变量

1
2
3
4
5
6
# crc 命令
echo 'export PATH=$PATH:$HOME/bin' >> ~/.bashrc
# oc 命令
echo 'export PATH="/home/loginid/.crc/bin/oc:$PATH"' >> ~/.bashrc
echo 'alias k=kubectl' >> ~/.bashrc
echo 'oc login -u developer https://api.crc.testing:6443' >> ~/.bashrc
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
# create project 
oc new-project my-project

# create http server
kubectl create deployment hello-node --image=registry.k8s.io/e2e-test-images/agnhost:2.43 -- /agnhost  netexec --tls-cert-file /home/loginid/test.crt --tls-private-key-file /home/loginid/test.key

# expose as service
oc expose deployment hello-node --port=8080

# https://www.baeldung.com/openssl-self-signed-cert
# prepare self-signed key remove -des3
openssl genrsa -out test.key 2048

# create csr
openssl req -key test.key -new -out test.csr

# sign
openssl x509 -signkey test.key -in test.csr -req -days 365 -out test.crt

# upload
scp -i ~/.ssh/oc_key.pem /mnt/d/Git/mypages/test.key loginid@hostip:/home/loginid/test.key

scp -i ~/.ssh/oc_key.pem /mnt/d/Git/mypages/test.crt loginid@hostip:/home/loginid/test.crt

# create secret https://www.baeldung.com/openssl-self-signed-cert
oc create secret generic my-cert --from-file=/home/loginid/test.crt --from-file=/home/loginid/test.key

# mount secret for deployment pods
oc apply -f deploy.yaml

# create route on haproxy from hostName=oc-dev.centralus.cloudapp.azure.com
oc create route passthrough test-pass --service=hello-node --port=8080 --hostname=oc-dev.centralus.cloudapp.azure.com.crc.testing

本地服务测试

1
2
3
4
5
6
7
8
9
10
11
12
13

# pod DNS

curl https://hello-node-7556f558d-psbrp:8080 -k

# service DNS

curl https://hello-node-svc.optimus.svc.cluster.local -k

# cluster DNS

curl https://oc-dev.centralus.cloudapp.azure.com.crc.testing -k -v

远程连接admin console

https://www.redhat.com/en/blog/accessing-codeready-containers-on-a-remote-server

在服务器端，需要利用haproxy做外部网卡IP的端口转发到内部地址127.0.0.1，建立外网网卡与内网之间的网桥.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
sudo apt install haproxy

sudo cp /etc/haproxy/haproxy.cfg /etc/haproxy/haproxy.cfg.bak

# 加上一下端口转发规则

frontend apps
    bind SERVER_IP:80
    bind SERVER_IP:443
    option tcplog
    mode tcp
    default_backend apps

backend apps
    mode tcp
    balance roundrobin
    option ssl-hello-chk
    server webserver1 CRC_IP check

frontend api
    bind SERVER_IP:6443
    option tcplog
    mode tcp
    default_backend api

backend api
    mode tcp
    balance roundrobin
    option ssl-hello-chk
    server webserver1 CRC_IP:6443 check

# 更改IP地址

export SERVER_IP=$(hostname --ip-address)
export CRC_IP=$(crc ip)
sudo sed -i "s/SERVER_IP/$SERVER_IP/g" haproxy.cfg
sudo sed -i "s/CRC_IP/$CRC_IP/g" haproxy.cfg

# 启动服务haproxy
sudo ststemctl start haproxy

# 诊断

sudo apt install net-tools

Java API创建Route资源

Useful Code example

https://github.com/kubernetes-client/java/wiki/3.-Code-Examples

Leader Election Example

https://github.com/kubernetes-client/java/blob/master/examples/examples-release-18/src/main/java/io/kubernetes/client/examples/LeaderElectionExample.java

0%