1 介绍
几乎所有的门户系统在实施的过程中都会出现门户系统和后台Web应用集成的场景。有一些应用系统可能就是SAP系统（这些提供Web访问的工具包括：ITS、BSP或者Web Dynpro），同时有些系统也可能是non-SAP系统。
该文档针对两种基于SAP NetWeaver EP的实现单点登录的方法：SAP Logon Ticket（SAP登录票）和User Mapping（用户映射）。
[注：本文档不描述针对数字证书的方式和非浏览器环境的后台系统]
2 什么是Single-Sign-On
Single-Sign-On简称SSO，通常被描述为允许终端用户只进行一次验证就可以登录多个应用。
SAP NetWeaver EP允许多种方式来实现于Web应用的单点登录，该文档假设用户的业务场景是采用门户系统来代替后台Web应用来实现用户的认证。
3 Portal到Web的单点登陆策略
3.1 SAP Logon Ticket
这种策略是采用存放在用户浏览器端的cookie来实现认证信息的存放。一旦在浏览器中存放了cookie以后，cookie会随着用户访问Portal中的各个业务系统转发到各个后台系统中，但这里有个前提，就是Portal和各个后台系统是分布在同一个域里面的。
当后台Web应用获取到cookie信息以后，它必须知道如何来处理认证信息。如果后台是SAP系统，那么两者的集成是有先天的优势的，SAP系统之间已经内建了相互的认证机制，可以很方便的解析这些加密的认证信息，如果是non-SAP系统，SAP也提供了多种可以处理加密认证信息的工具和管理SAP Logon Ticket cookie的框架。
优点：
降低企业IT系统的维护成本：使用SAP Logon Ticket后，后台系统完全“信任”SAP Portal的认证信息，portal不在cookie中传递用户的密码给后端Web应用。所以后端系统就不需要手工管理用户密码，也不需要在各个业务系统之间同步密码，大大降低了IT系统的维护成本。
SAP标准的单点登陆（SSO）机制：所有新发布的SAP系统（包括一些旧的SAP系统）内建了基于SAP Logon Ticket实现单点登陆的机制，所以当我们集成SAP系统时，需要作很少的工作，通过简单的配置就可以实现。
限制：
用户存储策略：SAP的企业门户只能为每个登陆用户建立一个存放用户信息的Cookie，所以当采用SAP Logon Ticket这种方式来连接多个后台系统时，先决条件是所有的这些系统必须要有一个相同的用户存储（在门户系统项目中，统一用户存储将是一个项目的难点）。使用登陆票来实现单点登陆最简单的场景是：门户系统的用户名与各后台系统的用户名相同。
与用户映射的冲突：某些SAP开发框架，例如BSP，支持SAP Logon Ticket或者User Mapping，一个后端系统一旦采用了SAP Logon Ticket cookie来传送用户信息就不能使用User Mapping。原因是一个采用相同用户名来建Session，一个是不一样的用户名。
3.2 User Mapping
用户映射是一种单点登录的实现方式，它的实现过程是portal服务器向后台系统传递用户名和密码，从而完成登录过程。当连接到web应用系统时，用户映射意味着通过请求的POST或GET方法传递用户名和密码。
有两种主要的用户映射实现方法——单独的用户映射和一般的用户映射
单独的用户映射
单独的用户映射中每个Portal用户被指定到一个唯一的后台系统用户。用户自己或管理员都可以完成指定。
一般的用户映射
一般的用户映射中多个用户被映射到一个后台系统的用户。用这种方法时，为了避免多个用户用同一个后台系统用户而产生冲突，通常由管理员来维护用户名和密码的映射。
用户映射的好处和优点
最小的技术调整：只要后台系统能从请求中接受用户名和密码，就不需要在后台系统上做任何配置。在portal端，也只需很少的配置，只需要创建一个系统对象并选好用户映射类型（“UIDPW”代表用户名和密码）。
简化后台用户管理（用一般用户映射时）：用凭票方式实现单点登录，需要后台系统管理所有可能登录进该系统的用户。这可能需要在后台系统中创建成千上万个与portal系统对应的用户。
在这种情况下，用后台系统中的几个一般性的用户来代表几种不同访问权限，而不需要为每个Portal用户建立单独的用户将更有吸引力。举个例子，假设后台系统有两种显示数据的级别——经理和员工。用一般性用户映射时，只需要建立两个后台系统的用户——用户“经理”和用户“员工”。每个portal用户映射到这两个用户之一。这种方法简化了后台系统的用户管理（只需管理两个用户）。
缺点和局限性
映射的维护量大：需要在portal系统中维护后台系统的用户名/密码。这个维护的工作量可能比较大，比如假如后台系统的密码需要每个月换一次，则portal里也需要做相应的修改。此外，如果允许用户维护自己的用户映射属性，就需要成立一个支持团队来处理用户锁定、忘记密码等情况。
安全：portal中存储密码始终是一个安全隐患。在两个地方（portal和后台系统中）维护密码也是不安全的。另外，用户映射方式在网路上传输用户名和密码到后台系统，在网络上也可能监听到密码。
用户映射需要的扩展或工作方式
安全通信：当使用用户映射方式时必须强制使用SSL和后台系统进行通信，否则密码会被完全暴露给网上进行监听的不怀好意的人。
基于组或角色的映射：映射portal中的组或角色到后台系统会减少管理员的工作量。尽管如此，需要指出的是用户映射不容易管理，同时只要一个用户能管理自己用户映射到单个系统，他就能对portal中所有被映射的系统进行管理。
改进的个性化：SAP Portal为每个可以进行用户映射的用户提供了标准的个性化窗口。但是，个性化工具有一个明显的缺点：需要用户知道portal中的系统别名和后台系统的关系。
在广泛使用用户映射，并且以上描述情况很可能会发生的情况下，建议创建一个可以被用来为特别系统处理用户映射的定制iView。这个iView可以嵌进相关的workset，因此最终用户会更加清楚他正在管理的是什么用户映射。从技术的角度，上面所描述的iView只需要简单地使用UME（用户管理引擎）的API。API提供了的storeLogonData方法，提供了存储用户映射数据到UME的功能。开发手册参见：
http://media.sdn.sap.com/html/submitted_docs/ume/ume40_0_index.htm