Object obj = SecurityContextHolder.getContext().getAuthentication().getPrincipal();
if( obj instanceof UserDetails){
 String username=((UserDetails)obj).getUsername();
}else{
 String username=obj.toString();
}

    上面这段代码介绍了不少有意思的对象和关系。首先，大家会发现在SecurityContextHolder和Authentication之间存在着一个即时对象：SecurityContext，SecurityContextHolder.GetContext()返回的类型就是SecurityContext。Acegi有数个SecurtiyContext的实现。

    另一个值得注意的是我们从Authentication中获得了一个规则。这个规则的类型是：Object。大多数情况下，我们可以把它强制性转换成UserDetails对象。UserDetails是Acegi的核心接口。它代表了一种规则，但是经过了应用相关的扩展。可以把UserDetails想象成为应用数据库与Acegi的SecurityContextHolder需要的两者之间的适配器（Adapter）。如果作为应用自己的数据库的代表，那么可以把UserDetails强制性转换为其原始类，这样，你就可以调用其中的业务方法（比如：getEmail()等等）。

    那么，为什么要提供一个UserDetails对象呢？是这样的：有一个特殊的接口：UserDetailsService，这个接口只有一个方法，这个方法接收一个String类型的表示用户名的参数，返回UserDetails对象。大多数认证提供provider装配一个代理到UserDetailsService上。UserDetailsService被用于创建SecurityContextHolder中存储的Authentication对象。Acegi中提供了若干个UserDetailsService的实现，一个使用内存Map，一个用JDBC。大多数用户倾向于写一个自己的实现，通常是使用DAO。不论UserDetailsService返回的是什么，都可以通过SecurityContextHolder获得。

    Authentication提供另一个重要的方法是getAuthorites()。这个方法返回一个GrantedAuthority对象的数组。GrantedAuthority是授权给的认证。这个认证通常指的是“角色”，比如：ROLE_ADMINISTRATOR或者ROLE_HR_SUPERVISOR。这些角色需配置用于web认证，方法认证和域对象认证。如果Acegi的其他部分希望看到这些认证，那么UserDetailsService返回GrantedAuthority对象即可。

    最后，有时你需要在HTTP requests之间传递SecurityContext，有时每次请求都需要重新认证。那么可以使用HttpSessionContextIntergrationFilter，这是用于在HTTP Request之间传递SecurityContext的东东。就象名称所表示的那样：HttpSession用于存储这些信息。但是你不需要直接操作HttpSession。