应答的关键部分是Assertion元素。断言使用了SAML Assertion名称空间定义的一个词汇表。它由一个验证语句组成，该语句告诉我们用户JSmith已通过口令验证。它还包含了支配目标站点断言使用的一系列条件。在本例中，这些条件指定一个10分钟的时间窗（time window），在时间窗之内断言有效。时间窗用来防止重放攻击。没有它，中途截取断言的恶意用户可以明天再次发送断言来冒充JSmith，并获得访问目标站点的权限。确认方法元素是指上面描述的浏览器凭证。

　　接受断言后，目标站点视为JSmith已直接通过其用户名和口令登录。注意，验证（鉴别用户身份）和授权（授予用户访问资源的权限）之间的分离在此是非常重要的。源站点负责验证JSmith，但不提供关于JSmith在目标站点特权的任何信息。这种安排对双方站点都有益处：源站点无需了解目标站点的资源或特权，目标站点也可忽略源站点管理用户和验证的细节。这种分离提供了非常重要的灵活性。

　　假设源站点是JSmith的老板MegaBank。JSmith使用他在MegaBank的账号访问他工作必需的三个不同外部宿主的应用程序。一天，MegaBank雇佣的安全顾问建议在JSmith所在部门启用指纹验证。如果没有SSO和SAML，MegaBank就必须到三个应用程序提供商那里请求他们支持指纹验证。应用程序提供商不得不权衡提供该支持的成本和不提供该支持可能丢失客户的风险。MegaBank可能必须等待提供商发布他们软件的新版本，所有的改动或许将昂贵又费时。通过SAML，MegaBank只需改变自己的验证过程，在JSmith和其同事登录时检查指纹即可。作为SAML目标站点的宿主应用程序无需清楚在MegaBank所做的更改，因为底层的SAML断言是保持不变的。

　　使用SAML对用户Web站点或Web服务的设计与实现有一些影响，但仅限于在处理Web窗口中的用户名和口令时，或在处理方法签名时。例如，下面的Web services API方法不能与SAML很好地协同工作：

　　public void makeSomeSystemChange(String username,
　　String password,
　　String[] params);