随笔 - 17, 文章 - 1, 评论 - 0, 引用 - 0
数据加载中……

2006年6月7日

Keystore 相关的一些概念

把一些常见的 Key 相关的内容列在这,便于之后理解。

1. JKS (Java KeyStore) 和 PFX (pkcs12) 都是常见的密钥库的格式,用于保存完整的证书密钥对,证书链和信任证书信息,前者是 Sun 制定的,适用于 Java 世界,比如 Tomcat,Geronimo,Websphere 等,后者"据说"常用于 IIS (没配置过) 等。JKS 相关的工具是 JDK 带的 keytool,PFX 可以使用 openssl。

2. JKS 中有存放的内容常见有两类,一个是 PrivateKeyEntry, 包含了完整的证书密钥对,证书链等信息,另外一个是 trustedCertEntry, 包含受信公钥信息。可以使用 keytool -list -keystore 显示。

3. 一般使用工具生成 RSA 非对称密钥对之后,还会由第三方机构 (CA) 生成签名,用于标识密钥所有者的身份,所以通常我们会说,我们将证书下发给客户端,此时的证书包括如下信息,公钥,签名信息等。

4. 使用 JKS 存储信息时,由于 Keystore 中可以存放多个密钥信息,所以通过会使用 alias 标识,需要使用时,需要指定别名。另外,Keystore 本身可以使用 storepassword 保护,而针对每一个 key,也可以是使用 keypassword 保护。

5. keytool 支持导入公钥和其他 keystore,暂不支持导入 PrivateKeyEntry,此时若手中有私钥和证书两个信息,只能先倒入到 PFX 中,再导入到 JKS 中。

openssl pkcs12 -export -in [my_certificate.crt] -inkey [my_key.key]
-out [keystore.p12] -name [new_alias] -CAfile [my_ca_bundle.crt] -caname
 root

keytool -importkeystore -deststorepass [new_keystore_pass]
-destkeypass [new_key_pass] -destkeystore [keystore.jks] -srckeystore
[keystore.p12] -srcstoretype PKCS12 -srcstorepass
[pass_used_in_p12_keystore] -alias [alias_used_in_p12_keystore]

6. JAR 签名,主要是在 META-INF 目录下,除了 MANIFEST.MF 之外,还有 *.SF 和 *.RSA 文件 (后缀随签名使用的算法会略有不同), MF 保存了 JAR 中每个文件的散列信息,一般使用 MD5 或者 SHA-1
Name: AndroidManifest.xml
SHA-256-Digest: vn9XTNvoXBMgbaxUqDoc4WUsWseMfRCQQRSR87+F/Hc=

SF 文件使用 RSAwithSHA1, 针对 MF 中的每条信息再次生成签名信息,另外针对整个 MF 也会生成签名信息。
Name: AndroidManifest.xml
SHA-256-Digest: Pa/g6cA3KpnfBvCD/mgnyczjfLCSkAv2l9A+EVxaJlg=

RSA 中是前述签名所用证书等相关信息

通常我们在读取 Jar 文件的每个 Entry 时,如果 META-INF 目录下有如上文件,会做签名验证,因为散列信息计算需要读取文件内容,所用在调用 getCertifcate 方法时,需要读一下流里面的内容,如果只是验证的目的,读取直接忽略即可,考虑读取性能,可以指定 byte[] buffer 的大小,使用流的 skip 方法时,内部 ZipInputStream 中使用的是
private byte[] tmpbuf = new byte[512];

7. 一般而言,证书有两种常见用途,一是用于传输加密,主要是 SSL,另外一个对文件进行签名,比如 JarFile 相关,而 CA 颁发证书时,会在证书中指定其用途,从目前看,以上两种不会同时生效,即若此证书声明为用于 SSL,则无法用于对 JarFile 进行签名,实际使用会发现 JarSign 时未显示错误,但通过 JarEntry 获取证书时一直为空。

posted @ 2015-06-07 14:16 一直在努力 ! 阅读(671) | 评论 (0)编辑 收藏

OAuth 2.0 Notes

最近研究 CloudFoudry 需要了解 UAA 相关东西, 并学习了 OAuth 的相关知识. 在网上找到两篇文章写得比较好

[1] http://blog.gopivotal.com/cloud-foundry-pivotal/products/open-standards-in-cloud-foundry-identity-services
[2] http://tutorials.jenkov.com/oauth2/index.html

Summary
Authorization Code 方式是最完整的, Client Application 会被重定向到 OAuth Server 登录并同意授权, 之后再返回业务系统, 业务系统通过 Authorization Code 在 OAuth Server 处获取访问最终 Resource Server 的 Access Token
Implicit 与 Authorization Code 大体类似, 只是少了用 Auhtorization Code 获取 AccessToken 的步骤
Resource Owner 方式是客户程序知道用户名和密码, 认证时连同自身的 Client ID 和密码一起发送到 OAuth Server, 比如 CF Java 客户端就是使用这种方式
Client Credentials 是 Client Application 本身就类似于 Resource Owner


1. OAuth Client 首先需要在 OAuth Server 注册, 需要提供一个 Redirect URL, 并从 OAuth Server 获取 Client ID 和 Client 密码
2. 基本流程
    a. 用户访问客户端应用程序
    b. 客户端应用重定向到 OAuth Server
    c. 用户输入用户名和密码登录, OAuth Server 执行完 Authentication 后, 会提示用户是否允许访问数据
    d. OAuth Server 使用注册的重定向 URL, 用户再次被定向到客户端应用程序, 此时 URL 会包含 Authentication Code
    e. 客户端应用程序接收到请求后, 使用 Authentication Code/Client ID/Client Password 访问 OAuth Server 获取 Access Token
    
3. OAuth 中四个角色
    a. Resource Owner : One person or one application
    b. Resource Server
    c. Client Application
    d. Authorization Server
    * b 和 d 可以在一起, OAuth 规范未作详细规定, 其之间如何交互也无规定
    
4. OAuth Client 类型
    a. Confidential
    b. Public
    OAuth 客户端需要持用 Client ID 和 Client Password, 两种类型的区别在于, 第三方是否可以通过某种方式获取该信息.

5. Client Profile
    a. Web Application 指运行在 Web 服务器上的 Web 应用, 实际场景中, 还可能包含客户端浏览器       
    b. User Agent 比如运行在浏览器中的 JavaScript 应用
    c. Native 比如桌面应用或者移动手机应用
    
6. OAuth 2.0 Authorization
    a. 注册到 OAuth 服务器, 一般执行一次, Client Application 会获取分配的 Client ID 和 Client Password. 注册过程中, Client Application 需要提供 Redirect URI
    This redirect URI is used when a resource owner grants authorization to the client application. When a resource owner has successfully authorized the client application via the authorization server, the resource owner is redirected back to the client application, to the redirect URI.
    b. 无论何时 Client Application 请求 Resource Server 上的资源时, Client Application 都需要到 OAuth Server 处使用 ID 和 密码执行认证
    
7. Authorization Grant 指 Resource Owner 授予 Client Application. OAuth 2.0 定义了如何类型 :
    a. Authorization Code
    b. Implicit
    c. Resource Owner Password Credentials
    d. Client Credentials
    
8. Authorization Code
    a. 当 Client Application 重定向到 OAuth Server 时, Client ID 也会被传递过去, 这样 Authorization Server 可以知道哪个应用 (Client Application) 试图访问受保护资源
    b. 当用户成功登录并授权访问后, OAuth Server 会使用 Client Application 注册时提供的 Redirect URI, 同时包含 Authentication Code.
    c. Client Application 使用 Authentication Code, Client ID 和 Client Password 直接访问 Authorization Server, 并过去 Access Token. Access Token 代表 Client Application 通过认证和授权访问保护资源. (The access token serves as both authentication of the client, and authorization to access the resources. )
    
9. Implicit 与 Authentication Code 工作方式类似, 区别在于重定向时, Access Token 被包含在内.
    a. An implicit authorization grant is similar to an authorization code grant, except the access token is returned to the client application already after the user has finished the authorization. The access token is thus returned when the user agent is redirected to the redirect URI.
    b. This of course means that the access token is accessible in the user agent, or native application participating in the implicit authorization grant. The access token is not stored securely on a web server.
    c. Furthermore, the client application can only send its client ID to the authorization server. If the client were to send its client secret too, the client secret would have to be stored in the user agent or native application too. That would make it vulnerable to hacking.
    d. Implicit authorization grant is mostly used in a user agent or native client application. The user agent or native application would receive the access token from the authorization server.
    
10. Resource Owner Password Credentials 等价于, 用户 (Resource Owner) 把用户名密码告诉 Client Application, 然后 Client Application 直接使用用户名和密码访问 Resource Server
     a. The resource owner password credentials authorization grant method works by giving the client application access to the resource owners credentials. For instance, a user could type his Twitter user name and password (credentials) into the client application. The client application could then use the user name and password to access resources in Twitter.
     b. Using the resource owner password credentials requires a lot of trust in the client application. You do not want to type your credentials into an application you suspect might abuse it.
     c. The resource owner password credentials would normally be used by user agent client applications, or native client applications.

11. Client Credentials 使用 Client Application 需要调用 Resource Server 提供的一些功能, 但这些功能不和任何 Resource Owner 相关
      Client credential authorization is for the situations where the client application needs to access resources or call functions in the resource server, which are not related to a specific resource owner (e.g. user). For instance, obtaining a list of venues from Foursquare. This does not necessary have anything to do with a specific Foursquare user.
      
12. OAuth 2.0 Endpoints
    a. Authorization Endpoint
        The authorization endpoint is the endpoint on the authorization server where the resource owner logs in, and grants authorization to the client application.
    b. Token Endpoint
        The token endpoint is the endpoint on the authorization server where the client application exchanges the authorization code, client ID and client secret, for an access token.
    c. Redirection Endpoint
         The redirect endpoint is the endpoint in the client application where the resource owner is redirected to, after having granted authorization at the authorization endpoint.
    
    a 和 b 位于 Authorization Server 上, c 位于客户端应用程序上
    
13. Authorization Code Grant Requests/Responses
    a. Authorization Request
        a1. response_type     Required. Must be set to code
        a2. client_id     Required. The client identifier as assigned by the authorization server, when the client was registered.
        a3. redirect_uri     Optional. The redirect URI registered by the client.
        a4. scope     Optional. The possible scope of the request.
        a5. state     Optional (recommended). Any client state that needs to be passed on to the client request URI.
    b. Authorization Response
         The authorization response contains the authorization code needed to obtain an access token. Here are the parameters included in the response:
         b1. code     Required. The authorization code.
         b2. state     Required, if present in request. The same value as sent by the client in the state parameter, if any.
    c. Authorization Error Response
          If an error occurs during authorization, two situations can occur.
          The first is, that the client is not authenticated or recognized. For instance, a wrong redirect URI was sent in the request. In that case the authorization server must not redirect the resource owner to the redirect URI. Instead it should inform the resource owner of the error.
          The second situation is that client is authenticated correctly, but that something else failed. In that case the following error response is sent to the client, included in the redirect URI:
          c1. error     Required. Must be one of a set of predefined error codes. See the specification for the codes and their meaning.
          c2. error_description     Optional. A human-readable UTF-8 encoded text describing the error. Intended for a developer, not an end user.
          c3. error_uri     Optional. A URI pointing to a human-readable web page with information about the error.
          c4. state     Required, if present in authorization request. The same value as sent in the state parameter in the request.         
    d. Token Request
         Once an authorization code is obtained, the client can use that code to obtain an access token. Here is the access token request parameters:
         d1. grant_type     Required. Must be set to authorization_code .
         d2. code     Required. The authorization code received by the authorization server.
         d3. redirect_uri     Required, if the request URI was included in the authorization request. Must be identical then.        
    e. Token Response
          The response to the access token request is a JSON string containing the access token plus some more information:

            { "access_token"  : "...",
              "token_type"    : "...",
              "expires_in"    : "...",
              "refresh_token" : "...",
            }

        e1. The access_token property is the access token as assigned by the authorization server.
        e2. The token_type property is a type of token assigned by the authorization server.
        e3. The expires_in property is a number of seconds after which the access token expires, and is no longer valid. Expiration of access tokens is optional.
        e4. The refresh_token property contains a refresh token in case the access token can expire. The refresh token is used to obtain a new access token once the one returned in this response is no longer valid.  
        
14. Implicit Grant Request
     a. The implicit grant request contains the following parameters:
        a1. response_type     Required. Must be set to token .
        a2. client_id     Required. The client identifier as assigned by the authorization server, when the client was registered.
        a3. redirect_uri     Optional. The redirect URI registered by the client.
        a4. scope     Optional. The possible scope of the request.
        a5. state     Optional (recommended). Any client state that needs to be passed on to the client request URI.

     b.Implicit Grant Response
        The implicit grant response contains the following parameters. Note, that the implicit grant response is not JSON.
        b1. access_token     Required. The access token assigned by the authorization server.
        b2. token_type     Required. The type of the token
        b3. expires_in     Recommended. A number of seconds after which the access token expires.
        b4. scope     Optional. The scope of the access token.
        b5. state     Required, if present in the autorization request. Must be same value as state parameter in request.

    c. Implicit Grant Error Response

        If an error occurs during authorization, two situations can occur.
        
        The first is, that the client is not authenticated or recognized. For instance, a wrong redirect URI was sent in the request. In that case the authorization server must not redirect the resource owner to the redirect URI. Instead it should inform the resource owner of the error.

        The second situation is that client is okay, but that something else happened. In that case the following error response is sent to the client, included in the redirect URI:
        c1. error     Required. Must be one of a set of predefined error codes. See the specification for the codes and their meaning.
        c2. error_description     Optional. A human-readable UTF-8 encoded text describing the error. Intended for a developer, not an end user.
        c3. error_uri     Optional. A URI pointing to a human-readable web page with information about the error.
        c4. state     Required, if present in authorization request. The same value as sent in the state parameter in the request.

15. Credentials Grant - Requests and Response
    a. Resource Owner Password Credentials Grant Request
        The request contains the following parameters:
        a1. grant_type     Required. Must be set to password
        a2. username     Required. The username of the resource owner, UTF-8 encoded.
        a3. password     Required. The password of the resource owner, UTF-8 encoded.
        a4. scope     Optional. The scope of the authorization.

    b. Resource Owner Password Credentials Grant Response
        The response is a JSON structure containing the access token. The JSON structure looks like this:

        { "access_token"  : "...",
          "token_type"    : "...",
          "expires_in"    : "...",
          "refresh_token" : "...",
        }

        b1. The access_token property is the access token as assigned by the authorization server.
        b2. The token_type property is a type of token assigned by the authorization server.
        b3. The expires_in property is a number of seconds after which the access token expires, and is no longer valid. Expiration of access tokens is optional.
        b4. The refresh_token property contains a refresh token in case the access token can expire. The refresh token is used to obtain a new access token once the one returned in this response is no longer valid.

16. Client Credentials Grant - Requests and Response
     a. The client credentials grant request contains the following parameters:
        a1. grant_type     Required. Must be set to client_credentials .
        a2. scope     Optional. The scope of the authorization.
        
    b. Client Credentials Grant Response
        The client credentials response contains the following parameters:

        { "access_token"  : "...",
          "token_type"    : "...",
          "expires_in"    : "...",
        }

        b1. The access_token property is the access token as assigned by the authorization server.
        b2. The token_type property is a type of token assigned by the authorization server.
        b3. The expires_in property is a number of seconds after which the access token expires, and is no longer valid. Expiration of access tokens is optional.

        A refresh token should not be included for this type of authorization request.        

posted @ 2014-04-08 23:43 一直在努力 ! 阅读(261) | 评论 (0)编辑 收藏

Apache Geronimo 3.0 - JSF Integration

    在 Geronimo 的所有历史版本中, 对 MyFaces 整合的内容比较少, 只是检查了以下是否有 FacesServlet 在 web.xml 文件中, 如果有则将 MyFaces 的 StartUpListener 添加到 web.xml 中.
     在 JSF 2.0 中, 添加了以下几个特性, 促使需要对整合的代码做些许修改
     a. ManagedBean annotation, 不得不说, 这个标识有些鸡肋, 事实上 JSF 规范也并不要求对其提供支持. 尤其是 JavaEE 6 中, 有了 WebBeans 之后. 后在在社区里面提了以下, 似乎也没什么人关心.
     b. 多个 faces-config 文件的排序功能
     由于以上两个功能, 使得在部署市需要做一些工作, 一是必须扫描出所有的使用 ManagedBean annotation 的 Java 类, 并为其构建本地 JNDI 目录, 否则那些 @EJB 什么的标签根本没法工作. 其次是速度问题, 默认情况下, MyFaces 会在启动时执行以上的两个功能, 对应用程序的影响比较大.
     当前的解决方法时, 参照在 Web 容器的处理方式, 使用一些可序列化的 Info 类, 将所有信息在部署时都生成好, 启动时直接反序列化, 再通过 MyFaces 的一些 SPI 传递过去, 避免每次启动时重复那些工作.

posted @ 2010-10-14 21:30 一直在努力 ! 阅读(213) | 评论 (0)编辑 收藏

Apache Geronimo 3.0 (一)

    以下都是刚开始 Geronimo 3.0 时写在开心网上的一些笔记, 现移到此处权作备份.

    Geronimo 3.0 框架重构的工作已进行大半,  说来惭愧, 我除了感叹大师们的思想和设计之外, 剩下的只有学习了, 不知何时才能与大师们煮酒论 Geronimo.
    本周末, 读了一些代码, 列了一些要点, 以备以后查询所需, 并与大家共享.
    1. 内核的创建.
        在 OSGI 环境中, 所有的组件都已 Bundle 的形式存在, Geronimo 所有的内核类和插件也不例外, 都是在 OSGI 的框架启动后被载入的, 再无原来的 BootStrap 之类的东西了. 如今的内核的初始化, 基本 Geronimo GBean 的载入和 Geronimo 插件的加载都放到 BootActivator 中, 会在第一个 Geronimo 的 Bundle 中处理, 并将 Kernel 通过 OSGI 的 Service 对外发布.
   2. 插件的读取
        原来的 RepositoryConfigurationStore 想来不会再用了, 如今 config.ser 文件的读取放在 ConfigurationActivator 之中,  在 Bundle 启动时会被读取. 同时通过 ConfigurationManager 的 loadConfiguration 方法加载, 如此做目的, 一来将插件的生命周期与 Bundle 的生命周期作了映射, 二来也有机会记录了 BundleContext 引用.
   3. 调用顺序
        BootActivator -> PersistentConfigurationListener -> loadConfiguration( Artifact ) -> ConfigurationActivator -> loadConfiguration (ConfigurationData)
        整个调用逻辑略显冗杂, 皆因 Bundle 的生命周期与 Configuration 的生命周期交合一起所致. 前几天, 我在论坛了回了贴, 窃以为, 既然 Kernel 依旧存在, 何不区分对待, 各管各得, 省得互相映射而导致这样那样的问题, 不好之处只是 Geronimo 没有与 OSGI 像现在一样结合在一起. 结果被大师们无视了, 想来有什么问题, 抑或大师们觉得俺们都弄得差不多了, 你再提个想法, 让俺们白干了 ! 以以往的经验, 前者居多, 记录在此, 今后弄明白了再添加说明, 印象会深刻一点.
    下周有机会, 要看一下类载入结构和插件依赖关系的变动, 这个应该是从 OSGI 之最大获益了.

    回忆了一下 Geronimo 进行 OSGI 整合之处的讨论, 当时有些还不怎么明白, 现在明朗多了.
总体上, 当时有这么些整合方案 :
    一种是将 OSGI 容器以插件的形式部署于 Geronimo 中, 形式和 Web 容器, EJB 容器等一样, 部署应用时, 通过检索应用的部署信息, 若与 OSGI 相关, 则部署到 OSGI 容器中, 其他类型的还是各回各家, 各找各妈. 显而易见, 这种方式是种无痛整合, 工作量只是开发一个新的插件.
    第二种方式, 就是 Geronimo 部署到 OSGI 环境中, 所有的 Geronimo 的 JAR 文件和插件均是以 Bundle 的形式存在于 OSGI 环境中, 好处自然是享受到 OSGI 的那些动态载入, 细粒度类载入器关联等. 依据 Geronimo 的 Kernel 是否存在, 这种方式又可以再做细分. Kernel 存在的情况下, 事实上也就是现在使用的方式, 首先启动内核, 之后由 ConfigurationManager 启动各个插件, 再将其加载到内核中去. 这种方式下, Geroniom Is Part Of OSGI, 整合依旧不是很彻底. 最好的自然是 Geronimo IS OSGI, 此时, 再无 Kernel, 再无 GBean, 天下大同, 皆为 Bundle. GBean 之流可以通过 blueprint 的服务来代替, 如此, Geronimo 则完全脱胎换骨了. 革命革命, 先革己命, 在此得到印证.
    另外, 我在想, 现在看, OSGI 几乎成了香馍馍, 感觉你的产品要是没使用 OSGI 架构, 都不好意思和别人打招呼. 我得承认, OSGI 确实有很多吸引人的地方, 但是应用于 Java EE 的环境下, 还有许多待改进的地方, 这估计也是出了那么多 RFC 的原因, 毕竟 OSGI 之处并不是想应用于企业应用的环境中, 正如 JAVA 之处是想用来做机顶盒的开发一样, 后来在 Web 环境下确大放异彩. 在整合的过程中, 出现了很多问题, 例如之前讨论的, RMI 类载入器的问题, 扩展类路径的问题, 均未在 OSGI 中得到完美解决. 如此整合 OSGI, 想来也是配合公司新推的EBA 的编程模型, 并为 WAS 先踩踩雷.
    以上内容, 均是随手而写, 是从我自己的理解和对大师的言论中推断而来, 大家看的时候自个注意.

    OSGI 中 Bundle 之间的依赖关系的处理比较直白, 在一个 Bunlde 安装之后的某个时机, 对其标注依赖关系进行解析, 如果万事俱备, 设置其为 Resolved 状态, 如果不满足, 则处于 INSTALLED 状态。 这种处理方式, 与 OSGI 是一个灵活易插拔的环境有关。
    而在 Geronimo 中, 可不能任其如此, 所有的 Geronimo 插件都在 geronimo-plugin.xml/config.ser 中标注了依赖关系。在启动插件时, 必需首先启动其所依赖的所有其他组件。
    在之前版本中, 这些都是由 ConfigurationManager 来处理的, 插件所以依赖的无非是其他插件或者类库文件, 对于前者, ConfigurationManager 会首先启动之, 而后者, 则之间将其加入当前类载入器路径中即可。
    当切换到 OSGI之后, 一切都变了 。 首当其冲的是那些类库文件, 即 JAR 文件, 它们成为了一个个 Bundle, 都有了鲜活的生命, 不可只将其放到类载入器路径中就一了百了, 需要俺们安装和启动之。  其次, 谁负责按顺启动这些插件, 之前是由 ConfigurationManager, 现在则在 DependencyManager (Bundle Extender)来处理。 究其原因, 个人感觉, 技术上不存在限制, 但从设计上而言, ConfigurationManager 管理的是 Geronimo 插件在 Geronimo 内核中的生命周期, 而在 OSGI 环境中,有 OSGI 环境中的组件处理依赖关系, 显得更自然些。(个人意见, 仅供参考)
    最后记录一下 DependencyManager 的处理逻辑, 它监听了每个 Bundle 的启动, 接收到安装事件之后, 会读取 geronimo-plugin.xml 文件中的依赖关系, 并尝试启动这些依赖组件。

posted @ 2010-10-14 21:18 一直在努力 ! 阅读(603) | 评论 (0)编辑 收藏

博客重新开张了 !

博客重新开张了 !

posted @ 2010-10-14 21:11 一直在努力 ! 阅读(128) | 评论 (0)编辑 收藏

移动梦网提供信息或增值服务

每一个通过移动梦网提供信息或增值服务的公司,移动都会给它们一个服务号码,如QQ的服务号码是 1700,如果你想终止这个公司的服务,只需要向该公司的号码发送内容为“00000”的短信即可,例如终止移动QQ,只需要将"00000"发往 1700即可。所有的公司的服务代码,可以通过 http://www.bmcc.com.cn 点击 "梦网合作" 再点击 "SP客服热线" ,就可查到。

reference from:http://hedong.3322.org/archives/000615.html

posted @ 2006-06-07 16:06 一直在努力 ! 阅读(239) | 评论 (0)编辑 收藏