个web application 拥有能够被共享多种资源。经常有许多敏感的信息在没有保护措施的情况下在开放性网络上传输。在这种环境下，实际上许多web application有一定程度的安全性要求。大多数的servlet containers有明确的机制和结构来达到这种要求。虽然保证和执行的细节可能有些不同，但是，都具有下面的特点：
1.Authentication:通讯实体相互验证对方的行为是以一个明确的身份在进行的一种机制。
2.Access control for resources：对某组用户来说，对数据库的某些操作是受到限制的，或对有些程序强调可用性，完整性或保密性的一种机制。
3.Data Integrity：数据在传递过程中保证不被第三方修改的一种机制。
4.Confidentiality or Data Privacy：保证数据只被那些授权使用的用户使用，能被安全传递的一种机制。
Java Servlet, JSP中安全性通过如下几各方式实现：
一、 Declarative Security
Declarative security指的是表达一个应用的安全结构，包括角色，存取控制，和在一个应用的外部表单所要求的验证。在web application中发布描述器是实施declarative security的一种主要的工具。
发布者把application所要求的逻辑完整性映射为在特定运行环境下的安全策略。在运行时，servlet container使用这些策略来强迫验证。
二 、Programmatic Security
当declarative security不能够完全表达一个application的安全模型时，就可以使用programmatic Security。Programmatic Security包括HttpServletRequest接口的下列方法：
getRemoteUser
isUserInRole
getUserPrincipal
getRemoteUser方法返回经过客户端验证的用户名。IsUserInRole向container的安全机制询问一个特定的用户是否在一个给定的安全角色中。GetUserPrinciple方法返回一个java.security.Pricipal对象。这些APIs根据远程用户的逻辑角色让servlet去完成一些逻辑判断。它也可以让servlet去决定当前用户的主要名字。如果getRemoteUser返回null值（这意味着没有用户被验证），那么isUserInRole就总会返回false，getUserPrinciple总会返回null。
三 、Roles
一个Roles就是由Application Developer和Assembler所定义的一个抽象的逻辑用户组。当一个application被发布的时候，Deployer就把这些角色映射到在运行环境中的安全认证，例如组或规则。
一个servlet container能够为规则执行一些说明或编程安全，这些规则是与调用这些principal的安全属性所输入的要求相联系的。例如：
1． 当deployer把一个安全角色映射为操作环境下的一个用户组，调用principle所属的用户组就从安全属性中获得。如果principle的用户组与在操作环境下的用户组相匹配，那么principle 就是一个安全角色。
2． 当deployeer把一个安全角色映射为一个在安全方针域中的principle名时，调用principle的确principle名就被从安全属性中提取出来。如果两者相同的话，调用的principle就是安全的。
四、Authentication
一个web 客端能够使用下面的一种机制来对web 服务器验证一个用户。
HTTP Digest Authentication
HTTPS Client Authentication
HTTP Basic Authentication
HTTP Based Authentication
五、HTTP Basic Authentication
HTTP Basic Authentication是一个定义在HTTP/1.1规范中的验证机制。这种机制是以用户名和密码为基础的。一个web server要求一个web client去验证一个用户。作为request的一部分，web server 传递被称之为realm的字符串，用户就是在它里面被验证的。注意：Basic Authentication机制的realm字符串不一定反映任何一种安全方针域。Web client得到这些用户名和密码，然后把它传递给web server。Web server然后在一个特定的领域验证这些用户。
由于密码是使用一种64位的编码来传递，而且目的server没有验证，所以Basic Authentication不是一种安全的验证协议。然而一些附加的保护像使用一种安全传输机制（HTTPS）或在网络层使用安全措施能够解决一些问题。
六、HTTP Digest Authentication
与HTTP Digest Authentication一样，HTTP Digest Authentication根据用户名和密码验证一个用户。然而密码的传输是通过一种加密的形式进行的，这就比Basic Authentication所使用的64位编码形式传递要安全的多。这种方法没有像HTTPS Client Authentication的个人密钥方案安全。由于Digest Authentication当前不被广泛使用，servlet containers不要求支持它但是鼓励去支持它。
七、HTTPS Client Authentication
使用HTTPS（HTTP over SSL）的终端用户验证是一种严格非验证机制。这种机制要求用户去处理公共密钥证明（Public Key Certification PKC）。当前，PKCs在e-commerce应用中是有用的。不适应J2EE的servlet containers不要求支持HTTPS协议。
八、Server Tracking of Authentication Information
就像映射在角色中的安全标识一样，运行环境是环境的说明而不是应用的说明。
1． 在web application的发布环境创建一个登录机制和策略。
2、 对发布在同一个container的application能够使用同样的验证信息来代表这些application的principal。
3、 仅仅当通过安全策略域时要求用户重新验证。
因此，一个servlet container要求在container层来跟踪这些验证信息，而不是在application层。允许一个经验证的用户拒绝一个使用其它资源的application，这些是通过受同样安全性标识限制的container管理的。