认证和安全性

improve this page | report issue


概述

MobileFirst 安全框架基于 OAuth 2.0 协议。 根据本协议,可通过定义访问资源的必需许可权的作用域来保护资源。 要访问受保护资源,客户机必须提供匹配的访问令牌,用于封装授予客户机的授权作用域。

OAuth 协议将授权服务器与托管资源的资源服务器的角色相分离。

  • 授权服务器管理客户机授权和令牌生成。
  • 资源服务器使用授权服务器来验证由客户机提供的访问令牌,并确保它匹配所请求资源的保护作用域。

安全框架围绕实施 OAuth 协议的授权服务器而构建,并公开客户机与之交互以获取访问令牌的 OAuth 端点。 安全框架提供构建块,用于在授权服务器和底层 OAuth 协议上实施定制授权逻辑。 缺省情况下,MobileFirst Server 也充当授权服务器。 但是,您可以配置 IBM WebSphere DataPower 设备以充当授权服务器并与 MobileFirst Server 进行交互。

然后,客户机应用程序可以使用这些令牌来访问资源服务器上的资源,这可以是 MobileFirst Server 本身或者外部服务器。 资源服务器会检查令牌的有效性,以确保可授权客户机访问所请求的资源。 资源服务器与授权服务器分离使您能够对在 MobileFirst Server 之外运行的资源实施安全性。

应用程序开发者通过为每个保护的资源定义所需的作用域,并实施安全性检查验证问题处理程序来保护对资源的访问。 服务器端安全框架和客户机端 API 用于处理 OAuth 消息交换以及与授权服务器的透明交互,从而使开发者能够仅专注于授权逻辑。

跳转至:

授权实体

访问令牌

MobileFirst 访问令牌是描述客户机授权许可权的数字签名实体。 在针对特定作用域授予客户机授权请求且认证客户机后,授权服务器的令牌端点会向客户机发送包含所请求的访问令牌的 HTTP 响应。

结构

MobileFirst 访问令牌包含以下信息:

  • 客户机标识:客户机的唯一标识。
  • 作用域:授予令牌的作用域(请参阅 OAuth 作用域)。 此作用域不包括必需的应用程序作用域
  • 令牌到期时间:令牌无效(到期)的时间(秒)。

令牌到期

授予的访问令牌将一直保持有效直至到期。 访问令牌的到期时间设置为作用域内所有安全性检查到期时间中最短的到期时间。 但是,如果到最短到期时间的时间段长于应用程序的最长令牌到期时间段,那么令牌的到期时间将设置为当前时间加上最长到期时间段。 缺省最长令牌到期时间段(有效持续时间)为 3600 秒(1 小时),但是可通过设置 maxTokenExpiration 属性的值进行配置。 请参阅“配置最长访问令牌到期时间段”。

通过使用以下一种备选方法配置应用程序的最长访问令牌到期时间段:

  • 使用 MobileFirst Operations Console
    • 选择 [您的应用程序] → 安全选项卡。
    • 令牌配置部分中,将最长令牌到期时间段(秒)字段的值设置为您的首选值,然后单击保存。 您可以随时重复此过程以更改最长令牌到期时间段,或者选择复原缺省值以恢复缺省值。
  • 编辑应用程序的配置文件
    1. 命令行窗口中,导航至项目的根文件夹并运行 mfpdev app pull
    2. 打开位于 [project-folder]\mobilefirst 文件夹的配置文件。
    3. 编辑文件:定义 maxTokenExpiration 属性,并将该值设置为最长的访问令牌到期时间段(秒):
      {
          ...
          "maxTokenExpiration": 7200
      }
    4. 通过运行以下命令部署更新的配置 JSON 文件:mfpdev app push

访问令牌请求的成功 HTTP 响应包含一个 JSON 对象以及访问令牌和其他数据。 以下是来自授权服务器的有效令牌响应的示例:

HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-store
Pragma: no-cache
{
    "token_type": "Bearer",
    "expires_in": 3600,
    "access_token": "yI6ICJodHRwOi8vc2VydmVyLmV4YW1",
    "scope": "scopeElement1 scopeElement2"
}

令牌响应 JSON 对象具有以下属性对象:

  • token_type:根据 OAuth 2.0 Bearer Token Usage 规范,令牌类型始终为“Bearer”
  • expires_in:访问令牌的到期时间(秒)。
  • access_token:生成的访问令牌(实际访问令牌长于示例中显示的值)。
  • scope:请求的作用域。

令牌本身 (access_token) 也包含 expires_inscope 信息。

注:如果使用低级别 WLAuthorizationManager 类并自行管理客户机与授权和资源服务器之间的 OAuth 交互,或者如果使用保密客户机,那么有效访问令牌响应结构则相关。 如果使用封装 OAuth 流以访问受保护资源的高级别 WLResourceRequest 类,那么安全框架为您执行访问令牌响应的处理工作。 请参阅客户机安全性 API保密客户机

刷新令牌

“刷新令牌”是一种特殊类型的令牌,可用于在访问令牌到期时获取新的访问令牌。要请求新的访问令牌,可以提供有效的刷新令牌。刷新令牌是长期令牌,与访问令牌相比,它们在更长的时间段内保持有效。

应用程序使用刷新令牌时必须谨慎,因为刷新令牌可以允许用户永久保持已认证。社交媒体应用程序、电子商务应用程序、产品目录浏览和此类实用程序应用程序(其中应用程序提供者不定期对用户进行认证)可以使用刷新令牌。经常要求用户认证的应用程序必须避免使用刷新令牌。

MobileFirst 刷新令牌

MobileFirst 刷新令牌是数字签名的实体,如访问令牌,用于描述客户机的授权许可权。刷新令牌可用于获取相同作用域的新访问令牌。在针对特定作用域授予客户机授权请求且认证客户机后,授权服务器的令牌端点会向客户机发送包含所请求的访问令牌和刷新令牌的 HTTP 响应。在访问令牌到期后,客户机将刷新令牌发送到授权服务器的令牌端点以获取一组新的访问令牌和刷新令牌。

结构

与 MobileFirst 访问令牌类似,MobileFirst 刷新令牌包含以下信息:

  • 客户机标识:客户机的唯一标识。
  • 作用域:授予令牌的作用域(请参阅 OAuth 作用域)。 此作用域不包括必需的应用程序作用域。
  • 令牌到期时间:令牌无效(到期)的时间(秒)。

令牌到期

刷新令牌的令牌到期时间段比典型的访问令牌到期时间段长。一旦授予刷新令牌,刷新令牌将一直保持有效直至到期。在此有效期内,客户机可以使用刷新令牌获取一组新的访问令牌和刷新令牌。刷新令牌的固定到期时间段为 30 天。每次客户机成功接收到一组新的访问令牌和刷新令牌时,刷新令牌到期都会重置,从而为客户机提供永不过期令牌体验。访问令牌到期规则保持相同,如访问令牌部分中所解释。

可以分别在客户机端和服务器端使用以下属性来启用刷新令牌功能。

客户机端属性 (Android)
文件名:mfpclient.properties
属性名称:wlEnableRefreshToken
属性值:true
例如,
wlEnableRefreshToken=true

客户机端属性 (iOS)
文件名:mfpclient.plist
属性名称:wlEnableRefreshToken
属性值:true
例如,
wlEnableRefreshToken=true

服务器端属性
文件名:server.xml
属性名称:mfp.security.refreshtoken.enabled.apps
属性值“;”分隔的应用程序捆绑软件标识

例如,


            <jndiEntry jndiName="mfp/mfp.security.refreshtoken.enabled.apps" value='"com.sample.android.myapp1;com.sample.android.myapp2"'/>
            

对不同的平台使用不同的捆绑软件标识。


以下是来自授权服务器的有效刷新令牌响应的示例:

        HTTP/1.1 200 OK
        Content-Type: application/json
        Cache-Control: no-store
        Pragma: no-cache
        {
            "token_type": "Bearer",
            "expires_in": 3600,
            "access_token": "yI6ICJodHRwOi8vc2VydmVyLmV4YW1",
            "scope": "scopeElement1 scopeElement2",
            "refresh_token": "yI7ICasdsdJodHRwOi8vc2Vashnneh "
        }
        

除了作为访问令牌响应结构的一部分解释的其他属性对象之外,刷新令牌响应还具有额外的属性对象 refresh_token


注:与访问令牌相比,刷新令牌是长期有效令牌。因此,必须谨慎使用刷新令牌功能。不需要定期进行用户认证的应用程序是使用刷新令牌功能的理想选择。

从 CD 更新 3 开始,MobileFirst 在 iOS 上支持刷新令牌功能。

安全性检查

安全性检查是实施安全逻辑来保护服务器端应用程序资源的服务器端实体。 安全性检查的简单示例是用户登录安全性检查,用于接收用户凭证,并针对用户注册表验证凭证。 另一个示例是预定义的 MobileFirst 应用程序真实性安全检查,用于验证移动应用程序的真实性,并因而防止非法尝试访问应用程序资源。 也可使用相同的安全性检查来保护多种资源。

安全性检查通常会发出安全验证问题,要求客户机以特定方式进行响应以通过检查。 此握手是作为 OAuth 访问令牌获取流程的一部分发生的。 客户机使用验证问题处理程序以处理来自安全性检查的验证问题。

内置安全性检查

以下预定义安全性检查可用:

验证问题处理程序

在尝试访问受保护资源时,客户机可能面临验证问题。 验证问题是服务器发出的问题、安全测试和提示,用于确定允许客户机访问此资源。 最常见的情况是,该验证问题是对凭证的请求,例如,用户名和密码。

验证问题处理程序是客户机端实体,实施客户机端安全逻辑和相关的用户交互。 重要信息:在收到验证问题后,不能将其忽略。 必须回答或者取消。 忽略验证问题可能会导致意外的行为。

创建安全性检查教程中了解有关安全性检查的更多信息,并在凭证验证教程中了解有关验证问题处理程序的更多信息。

作用域

您可以通过向资源分配作用域,保护资源(例如,适配器)免遭未经授权的访问。

将作用域定义为由一个或多个以空格分隔的作用域元素组成的字符串(“scopeElement1 scopeElement2 …”),或者,如果要应用缺省作用域 (RegisteredClient),那么定义为 null。 要访问任何适配器资源,MobileFirst 安全框架都要求提供访问令牌,即使没有为资源分配作用域,也是如此;除非您对该资源禁用了资源保护。 请参阅保护适配器资源

作用域元素

作用域元素可以为以下之一:

  • 安全性检查的名称。
  • 任意关键字,例如,access-restricteddeletePrivilege,用于定义此资源所需的安全级别。 之后可将此关键字映射到安全性检查。

作用域映射

缺省情况下,在作用域中编写的作用域元素将映射到具有相同名称的安全性检查。 例如,如果编写名为 PinCodeAttempts 的安全性检查,那么可在作用域中使用具有相同名称的作用域元素。

作用域映射允许将作用域元素映射到安全性检查。 在客户机请求作用域元素时,此配置定义应该应用的安全性检查。 例如,您可以将作用域元素 access-restricted 映射到 PinCodeAttempts 安全性检查。

如果想要根据尝试访问资源的应用程序以不同方式保护资源,那么作用域映射非常有用。 您还可以将一个作用域映射到包含零项或多项安全性检查的列表。

例如: scope = access-restricted deletePrivilege

  • 在应用程序 A 中
    • access-restricted 映射到 PinCodeAttempts
    • deletePrivilege 映射到空字符串。
  • 在应用程序 B 中
    • access-restricted 映射到 PinCodeAttempts
    • deletePrivilege 映射到 UserLogin

要将作用域元素映射到空字符串,请勿在添加新作用域元素映射弹出菜单中选择任何安全性检查。

作用域映射

您还可以使用必需的配置来手动编辑应用程序的配置 JSON 文件,并将更改推送回 MobileFirst Server。

  1. 命令行窗口导航至项目的根文件夹,然后运行 mfpdev app pull
  2. 打开位于 [project-folder]\mobilefirst 文件夹的配置文件。
  3. 编辑文件:定义 scopeElementMapping 属性,在此属性中,定义由选中的作用域元素的名称和零项或多项空格分隔的安全性检查(将元素映射到此检查)的字符串组成的数据对。 例如:

     "scopeElementMapping": {
         "UserAuth": "UserAuthentication",
         "SSOUserValidation": "LtpaBasedSSO CredentialsValidation"
     }
    
  4. 运行以下命令来部署更新的配置 JSON 文件:mfpdev app push

您还可以将更新的配置推送到远程服务器。 请查看使用 MobileFirst CLI 来管理 MobileFirst 工件教程。

保护资源

在 OAuth 模型中,受保护资源是需要访问令牌的资源。 您可以使用 MobileFirst 安全框架来保护在 MobileFirst Server 实例上托管的资源以及外部服务器上的资源。 您可以通过为资源分配定义必需的许可权(用于获取资源的访问令牌)的作用域来保护资源。

您可以通过各种方式来保护资源:

必需的应用程序作用域

可以在应用程序级别定义应用于应用程序所使用的所有资源的作用域。 除了所请求资源作用域的安全性检查,安全框架还运行这些检查(如果存在)。

注:

  • 在访问不受保护的资源时,不会应用必需的应用程序作用域。
  • 为资源作用域授予的访问令牌不包含必需的应用程序作用域。


在 MobileFirst Operations Console 中,从导航侧边栏的应用程序部分选择应用程序,然后选择安全性选项卡。 在必需的应用程序作用域下,选择添加到作用域

必需的应用程序作用域

您还可以使用必需的配置来手动编辑应用程序的配置 JSON 文件,并将更改推送回 MobileFirst Server。

  1. 命令行窗口导航至项目的根文件夹,然后运行 mfpdev app pull
  2. 打开位于 project-folder\mobilefirst 文件夹中的配置文件。
  3. 通过定义 mandatoryScope 属性,并将属性值设置为包含选中作用域元素的空格分隔列表的作用域字符串来编辑文件。 例如:

    "mandatoryScope": "appAuthenticity PincodeValidation"
    
  4. 运行以下命令来部署更新的配置 JSON 文件:mfpdev app push

您还可以将更新的配置推送到远程服务器。 请查看使用 MobileFirst CLI 来管理 MobileFirst 工件教程。

保护适配器资源

在适配器中,可以对 Java 方法、JavaScript 资源过程或整个 Java 资源类指定保护作用域,如以下 JavaJavaScript 部分中所述。 将作用域定义为由一个或多个以空格分隔的作用域元素组成的字符串(“scopeElement1 scopeElement2 …”),或者,如果要应用缺省作用域 ,那么定义为 null(请参阅 作用域)。

缺省 MobileFirst 作用域为 RegisteredClient,需要访问令牌才能访问资源;缺省作用域会验证资源请求是否来自在 MobileFirst Server 中注册的应用程序。 将始终应用此保护措施,除非您禁用资源保护。 因此,即使没有为资源设置作用域,资源仍受保护。

注:RegisteredClient 是保留的 MobileFirst 关键字。 请勿使用此名称定义定制的作用域元素或安全性检查。

保护 Java 适配器资源

要向 JAX-RS 方法或类分配保护作用域,请向方法或类声明添加 @OAuthSecurity 注释,并将注释的 scope 元素设置为您的首选作用域。 将 YOUR_SCOPE 替换为由一个或多个作用域元素组成的字符串(“scopeElement1 scopeElement2 …”):

@OAuthSecurity(scope = "YOUR_SCOPE")

类作用域适用于类中的所有方法,但自身具有 @OAuthSecurity 注释的方法除外。

注:@OAuthSecurity 注释的 enabled 元素设置为 false 时,将忽略 scope 元素。 请参阅禁用 Java 资源保护

示例

以下代码使用包含 UserAuthenticationPincode 作用域元素的作用域来保护 helloUser 方法:

@GET
@Path("/{username}")
@OAuthSecurity(scope = "UserAuthentication Pincode")
public String helloUser(@PathParam("username") String name){
    ...
}

以下代码使用预定义的 LtpaBasedSSO 安全性检查来保护 WebSphereResources 类:

@Path("/users")
@OAuthSecurity(scope = "LtpaBasedSSO")
public class WebSphereResources {
    ...
}

保护 JavaScript 适配器资源

要向 JavaScript 过程分配保护作用域,请在 adapter.xml 文件中将 <procedure> 元素的作用域属性设置为您的首选作用域。 将 PROCEDURE_NANE 替换为您过程的名称,将 YOURSCOPE 替换为由一个或多个作用域元素组成的字符串(“scopeElement1 scopeElement2 …”):

<procedure name="PROCEDURE_NANE" scope="YOUR_SCOPE">

注:将 <procedure> 元素的 secured 属性设置为 false 时,将忽略 scope 属性。 请参阅禁用 JavaScript 资源保护

示例

以下代码使用包含 UserAuthenticationPincode 作用域元素的作用域来保护 userName 过程:

<procedure name="userName" scope="UserAuthentication Pincode">

禁用资源保护

您可以对特定的 Java 或 JavaScript 适配器资源或者整个 Java 类禁用缺省的 MobileFirst 资源保护,如以下 JavaJavaScript 部分中所述。 如果禁用资源保护,那么 MobileFirst 安全框架不需要令牌即可访问资源。 请参阅不受保护的资源

禁用 Java 资源保护

要对 Java 资源方法或类完全禁用 OAuth 保护,请向资源或类声明添加 @OAuthSecurity 注释,并将 enabled 元素的值设置为 false

@OAuthSecurity(enabled = false)

注释的 enabled 元素的缺省值为 true。 如果将 enabled 元素设置为 false,那么会忽略 scope 元素,因此资源或资源类将不受保护

注:在向不受保护的类的方法分配作用域后,该方法将受到保护,而不论类注释是何内容;除非您将资源注释的 enabled 元素设置为 false

示例

以下代码将对 helloUser 方法禁用资源保护:

    @GET
    @Path("/{username}")
    @OAuthSecurity(enabled = "false")
    public String helloUser(@PathParam("username") String name){
        ...
    }

以下代码将对 MyUnprotectedResources 类禁用资源保护:

    @Path("/users")
    @OAuthSecurity(enabled = "false")
    public class MyUnprotectedResources {
        ...
    }

禁用 JavaScript 资源保护

要对 JavaScript 适配器资源(过程)完全禁用 OAuth 保护,请在 adapter.xml 文件中将 <procedure> 元素的 secured 属性设置为 false

<procedure name="procedureName" secured="false">

如果将 secured 属性设置为 false,那么会忽略 scope 属性,因此资源将不受保护

示例

以下代码将对 userName 过程禁用资源保护:

<procedure name="userName" secured="false">

不受保护的资源

不受保护的资源是不需要访问令牌的资源。 MobileFirst 安全框架不会管理对不受保护资源的访问,并且不会验证或检查访问这些资源的客户机的身份。 因此,对于不受保护的资源,不支持诸如直接更新、阻止设备访问或远程禁用应用程序之类的功能。

保护外部资源

要保护外部资源,可向外部资源服务器添加包含访问令牌验证模块的资源过滤器。 令牌验证模块使用安全框架授权服务器的自省端点来验证 MobileFirst 访问令牌,然后再授权 OAuth 客户机访问资源。 您可以将 MobileFirst REST API 用于 MobileFirst 运行时,以针对任何外部服务器创建自己的访问令牌验证模块。 或者,使用一个提供的 MobileFirst 扩展来保护外部 Java 资源,如保护外部资源教程中所述。

授权流

授权流具有两个阶段:

  1. 客户机获取访问令牌。
  2. 客户机使用令牌来访问受保护资源。

获取访问令牌

在此阶段中,客户机进行安全性检查以接收访问令牌。

在请求访问令牌之前,客户机向 MobileFirst Server 注册自身。 在注册过程中,客户机提供将用于认证其身份的公用密钥。 在移动应用程序实例生命周期中,此阶段发生一次。 如果启用了应用程序真实性安全检查,那么在注册期间将验证应用程序的真实性。

获取令牌

  1. 客户机应用程序发送请求以获取指定作用域的访问令牌。

    客户机请求具有特定作用域的访问令牌。请求的作用域应映射到与客户机想要访问的受保护资源的作用域相同的安全性检查,而且也可以选择映射到其他安全性检查。 如果客户机先前不知道受保护资源的作用域,那么首先可请求具有空作用域的访问令牌,然后尝试使用获取的令牌访问资源。 客户机将收到一个响应,包含 403(禁止)错误以及所请求资源的必需作用域。

  2. 客户机应用程序将根据请求的作用域进行安全性检查。

    MobileFirst Server 运行要将客户机请求的作用域映射到的安全性检查。 授权服务器将根据这些检查的结果授权或拒绝客户机请求。 如果定义了必需的应用程序作用域,那么除了请求的作用域检查,还会运行此作用域的安全性检查。

  3. 在成功完成验证问题流程后,客户机应用程序会将请求转发给授权服务器。

    在成功授权后,客户机将重定向到授权服务器的令牌端点,在此处将使用在客户机注册期间提供的公用密钥对其进行认证。在成功认证后,授权服务器会向客户机发出数字签名的访问令牌,此令牌封装客户机标识、请求的作用域和令牌的到期时间。

  4. 客户机应用程序接收访问令牌。

使用令牌来访问受保护资源

可以针对在 MobileFirst Server 上运行的资源(如此图中所示)以及在任何外部资源服务器上运行的资源(如教程使用 MobileFirst Server 来认证外部资源中所解释)实施安全性。

在获取访问令牌后,客户机将获取的令牌附加到后续请求以访问受保护资源。 资源服务器使用授权服务器的自省端点来验证令牌。 验证包括使用令牌的数字签名来验证客户机的身份,验证作用域与授权的请求作用域是否匹配以及确保令牌未到期。 在验证令牌后,将授权客户机访问资源。

保护资源

  1. 客户机应用程序发送包含已收到令牌的请求。
  2. 验证模块会验证令牌。
  3. MobileFirst Server 继续进行适配器调用。

后续关注教程

通过关注侧边栏导航中的教程,继续阅读 MobileFirst Foundation 中有关认证的信息。

Inclusive terminology note: The Mobile First Platform team is making changes to support the IBM® initiative to replace racially biased and other discriminatory language in our code and content with more inclusive language. While IBM values the use of inclusive language, terms that are outside of IBM's direct influence are sometimes required for the sake of maintaining user understanding. As other industry leaders join IBM in embracing the use of inclusive language, IBM will continue to update the documentation to reflect those changes.
Last modified on June 19, 2020