标签归档:sso

CAS单点登录原理以及debug跟踪登录流程

CAS 原理和协议

基础模式

基础模式 SSO 访问流程主要有以下步骤:

1. 访问服务: SSO 客户端发送请求访问应用系统提供的服务资源。

2. 定向认证: SSO 客户端会重定向用户请求到 SSO 服务器。

3. 用户认证:用户身份认证。

4. 发放票据: SSO 服务器会产生一个随机的 Service Ticket 。

5. 验证票据: SSO 服务器验证票据 Service Ticket 的合法性,验证通过后,允许客户端访问服务。

6. 传输用户信息: SSO 服务器验证票据通过后,传输用户认证结果信息给客户端。

下面是 CAS 最基本的协议过程:

基础协议图

如 上图: CAS Client 与受保护的客户端应用部署在一起,以 Filter 方式保护 Web 应用的受保护资源,过滤从客户端过来的每一个 Web 请求,同 时, CAS Client 会分析 HTTP 请求中是否包含请求 Service Ticket( ST 上图中的 Ticket) ,如果没有,则说明该用户是没有经过认证的;于是 CAS Client 会重定向用户请求到 CAS Server ( Step 2 ),并传递 Service (要访问的目的资源地址)。 Step 3 是用户认证过程,如果用户提供了正确的 Credentials , CAS Server 随机产生一个相当长度、唯一、不可伪造的 Service Ticket ,并缓存以待将来验证,并且重定向用户到 Service 所在地址(附带刚才产生的 Service Ticket ) , 并为客户端浏览器设置一个 Ticket Granted Cookie ( TGC ) ; CAS Client 在拿到 Service 和新产生的 Ticket 过后,在 Step 5 和 Step6 中与 CAS Server 进行身份核实,以确保 Service Ticket 的合法性。

在该协议中,所有与 CAS Server 的交互均采用 SSL 协议,以确保 ST 和 TGC 的安全性。协议工作过程中会有 2 次重定向 的过程。但是 CAS Client 与 CAS Server 之间进行 Ticket 验证的过程对于用户是透明的(使用 HttpsURLConnection )。

CAS 请求认证时序图如下:

CAS 如何实现 SSO

当用户访问另一个应用的服务再次被重定向到 CAS Server 的时候, CAS Server 会主动获到这个 TGC cookie ,然后做下面的事情:

1) 如果 User 持有 TGC 且其还没失效,那么就走基础协议图的 Step4 ,达到了 SSO 的效果;

2) 如果 TGC 失效,那么用户还是要重新认证 ( 走基础协议图的 Step3) 。

以上是在网络上找到的相关描述,详细请参考:

http://www.open-open.com/lib/view/open1432381488005.html

但是光看文字描述还是不够清晰,不如Debug来看一下。

----------------------------------------------------------------------------------

前提:

有两个web应用

app1.testcas.com

app2.testcas.com

Cas认证中心

demo.testcas.com

第一步:访问目标应用app1

如果想要访问app1的网页

例如:app1.testcas.com/user/doWelcome

这时,该请求将会被事先配置好的CAS Filter所拦截

app1的web.xml配置如下:

<filter>
        <filter-name>CAS Filter</filter-name>
        <filter-class>org.jasig.cas.client.authentication.AuthenticationFilter</filter-class>
        <init-param>
            <param-name>casServerLoginUrl</param-name>
            <param-value>https://demo.testcas.com/cas/login</param-value>
        </init-param>
        <init-param>
            <param-name>serverName</param-name>
            <param-value>http://app1.testcas.com</param-value>
        </init-param>
</filter>
<filter-mapping>
    <filter-name>CAS Filter</filter-name>
    <url-pattern>/*</url-pattern>
</filter-mapping>
断点进入该类的doFilter方法

org.jasig.cas.client.authentication.AuthenticationFilter > doFilter
public final void doFilter(final ServletRequest servletRequest,
            final ServletResponse servletResponse, final FilterChain filterChain)
            throws IOException, ServletException
    {
        final HttpServletRequest request = (HttpServletRequest) servletRequest;
        final HttpServletResponse response = (HttpServletResponse) servletResponse;
        final HttpSession session = request.getSession(false);
        
        // 该变量为判断用户是否已经登录的标记,在用户成功登录后会被设置
        final Assertion assertion = session != null ? (Assertion) session.getAttribute(CONST_CAS_ASSERTION)
                : null;
        
        // 判断是否登录过,如果已经登录过,进入if并且退出
        if (assertion != null)
        {
            filterChain.doFilter(request, response);
            return;
        }
        // 如果没有登录过,继续后续处理
        
        // 构造访问的URL,如果该Url包含tikicet参数,则去除参数
        final String serviceUrl = constructServiceUrl(request, response);
        // 如果ticket存在,则获取URL后面的参数ticket
        final String ticket = CommonUtils.safeGetParameter(request,
                getArtifactParameterName());
        // 研究中
        final boolean wasGatewayed = this.gatewayStorage.hasGatewayedAlready(request,
                serviceUrl);
        
        // 如果ticket存在
        if (CommonUtils.isNotBlank(ticket) || wasGatewayed)
        {
            filterChain.doFilter(request, response);
            return;
        }
        
        final String modifiedServiceUrl;
        
        log.debug("no ticket and no assertion found");
        if (this.gateway)
        {
            log.debug("setting gateway attribute in session");
            modifiedServiceUrl = this.gatewayStorage.storeGatewayInformation(request,
                    serviceUrl);
        }
        else
        {
            modifiedServiceUrl = serviceUrl;
        }
        
        if (log.isDebugEnabled())
        {
            log.debug("Constructed service url: " + modifiedServiceUrl);
        }
        
        // 如果用户没有登录过,那么构造重定向的URL
        final String urlToRedirectTo = CommonUtils.constructRedirectUrl(this.casServerLoginUrl,
                getServiceParameterName(),
                modifiedServiceUrl,
                this.renew,
                this.gateway);
        
        if (log.isDebugEnabled())
        {
            log.debug("redirecting to \"" + urlToRedirectTo + "\"");
        }
        
        // 重定向跳转到Cas认证中心
        response.sendRedirect(urlToRedirectTo);
    }

第二步:请求被重定向到CAS服务器端后

根据CAS_Server端的login-webflow.xml配置

 View Code

首先会进入initialFlowSetupAction

 protected Event doExecute(final RequestContext context) throws Exception {
        final HttpServletRequest request = WebUtils.getHttpServletRequest(context);
        if (!this.pathPopulated) {
            final String contextPath = context.getExternalContext().getContextPath();
            final String cookiePath = StringUtils.hasText(contextPath) ? contextPath + "/" : "/";
            logger.info("Setting path for cookies to: "
                + cookiePath);
            this.warnCookieGenerator.setCookiePath(cookiePath);
            this.ticketGrantingTicketCookieGenerator.setCookiePath(cookiePath);
            this.pathPopulated = true;
        }

        // 获取客户端的名为CASTGC的cookie
        context.getFlowScope().put(
            "ticketGrantingTicketId", this.ticketGrantingTicketCookieGenerator.retrieveCookieValue(request));
        context.getFlowScope().put(
            "warnCookieValue",
            Boolean.valueOf(this.warnCookieGenerator.retrieveCookieValue(request)));

        // 获取要访问的服务
        final Service service = WebUtils.getService(this.argumentExtractors,
            context);

        if (service != null && logger.isDebugEnabled()) {
            logger.debug("Placing service in FlowScope: " + service.getId());
        }

        context.getFlowScope().put("service", service);

        return result("success");
    }

之后根据webflow流程,主要有两大分歧

如果TGC并且service存在,则发放ST(service ticket)并重定向回到客户端应用

如果首次访问,TGC不存在,则跳转到CAS-server的登录页面,如下(本登录页面是重新绘制,不是CAS原生登录页)

因为我是首次登录,所以会跳转到该登录页进行认证。

第三步:用户认证

输入用户名、密码、验证码,点击登录

这时再来看login-webflow.xml

用户提交登录后,按流程依次是

1.authenticationViaFormAction.doBind

    <view-state id="viewLoginForm" view="casMyLoginView" model="credentials">
        <binder>
            <binding property="username" />
            <binding property="password" />
            <binding property="imgverifycode" />
        </binder>
        <on-entry>
            <set name="viewScope.commandName" value="'credentials'" />
        </on-entry>
        <transition on="submit" bind="true" validate="true" to="imgverifycodeValidate">
            <evaluate
                expression="authenticationViaFormAction.doBind(flowRequestContext, flowScope.credentials)" />
        </transition>
    </view-state>
=>

2.imgverifycodeValidate(验证码处理为自定义的处理,不是原生逻辑)

    <action-state id="imgverifycodeValidate">
        <evaluate
            expression="authenticationViaFormAction.validatorCode(flowRequestContext, flowScope.credentials, messageContext)" />
        <transition on="error" to="generateLoginTicket" />
        <transition on="success" to="realSubmit" />
    </action-state>

=>

3.realSubmit

<action-state id="realSubmit">
        <evaluate
            expression="authenticationViaFormAction.submit(flowRequestContext, flowScope.credentials, messageContext)" />
        <transition on="warn" to="warn" />
        <transition on="success" to="sendTicketGrantingTicket" />
        <transition on="error" to="generateLoginTicket" />
    </action-state>

realSubmit中执行的是authenticationViaFormAction.submit

 public final String submit(final RequestContext context,
            final Credentials credentials, final MessageContext messageContext)
            throws Exception
    {
        // Validate login ticket
        final String authoritativeLoginTicket = WebUtils.getLoginTicketFromFlowScope(context);
        final String providedLoginTicket = WebUtils.getLoginTicketFromRequest(context);
        if (!authoritativeLoginTicket.equals(providedLoginTicket))
        {
            this.logger.warn("Invalid login ticket " + providedLoginTicket);
            final String code = "INVALID_TICKET";
            messageContext.addMessage(new MessageBuilder().error()
                    .code(code)
                    .arg(providedLoginTicket)
                    .defaultText(code)
                    .build());
            return "error";
        }
        
        // 获取TGT,首次登录的话应该是不存在的,所以直接跳过该分歧
        final String ticketGrantingTicketId = WebUtils.getTicketGrantingTicketId(context);
        final Service service = WebUtils.getService(context);
        if (StringUtils.hasText(context.getRequestParameters().get("renew"))
                && ticketGrantingTicketId != null && service != null)
        {
            
            try
            {
                final String serviceTicketId = this.centralAuthenticationService.grantServiceTicket(ticketGrantingTicketId,
                        service,
                        credentials);
                WebUtils.putServiceTicketInRequestScope(context,
                        serviceTicketId);
                putWarnCookieIfRequestParameterPresent(context);
                return "warn";
            }
            catch (final TicketException e)
            {
                if (e.getCause() != null
                        && AuthenticationException.class.isAssignableFrom(e.getCause()
                                .getClass()))
                {
                    populateErrorsInstance(e, messageContext);
                    return "error";
                }
                this.centralAuthenticationService.destroyTicketGrantingTicket(ticketGrantingTicketId);
                if (logger.isDebugEnabled())
                {
                    logger.debug("Attempted to generate a ServiceTicket using renew=true with different credentials",
                            e);
                }
            }
        }
        
        try
        {
            // 首次登录时,用户输入信息验证成功后,创建一个新的TGT
            WebUtils.putTicketGrantingTicketInRequestScope(context,
                    this.centralAuthenticationService.createTicketGrantingTicket(credentials));
            putWarnCookieIfRequestParameterPresent(context);
            return "success";
        }
        catch (final TicketException e)
        {
            // 如果用户输入信息验证不通过,会抛出异常,并在页面上显示
            populateErrorsInstance(e, messageContext);
            return "error";
        }
    }

=>

4.用户信息认证通过,并且创建了新的TGT后,缓存TGT,并且生成cookie,待后续把cookie写入客户端

    <action-state id="sendTicketGrantingTicket">
        <evaluate expression="sendTicketGrantingTicketAction" />
        <transition to="serviceCheck" />
    </action-state>
sendTicketGrantingTicketAction.doExecute
    protected Event doExecute(final RequestContext context) {
        final String ticketGrantingTicketId = WebUtils.getTicketGrantingTicketId(context); 
        final String ticketGrantingTicketValueFromCookie = (String) context.getFlowScope().get("ticketGrantingTicketId");
        
        if (ticketGrantingTicketId == null) {
            return success();
        }
        
        // 生成Cookie并且写入response,最终在客户端Cookie中保存了本TGT
        this.ticketGrantingTicketCookieGenerator.addCookie(WebUtils.getHttpServletRequest(context), WebUtils
            .getHttpServletResponse(context), ticketGrantingTicketId);

        if (ticketGrantingTicketValueFromCookie != null && !ticketGrantingTicketId.equals(ticketGrantingTicketValueFromCookie)) {
            this.centralAuthenticationService
                .destroyTicketGrantingTicket(ticketGrantingTicketValueFromCookie);
        }

        return success();
    }

=>

5. 然后验证是否存在Service,如果存在,生成ST,重定向用户到 Service 所在地址(附带该ST ) , 并为客户端浏览器设置一个 Ticket Granted Cookie ( TGC ) 

serviceCheck => generateServiceTicket => warn => redirect =>postRedirectDecision

第四步:拿着新产生的ST,到 CAS Server 进行身份核实,以确保 Service Ticket 的合法性。

当cas Service重定向到客户端所在service时,该重定向请求同样会被客户端配置的过滤器所拦截,又进入了第一步处的AuthenticationFilter

但是由于本次请求已经带回了ST(service ticket),所以处理与首次有所不同。

public final void doFilter(final ServletRequest servletRequest,
            final ServletResponse servletResponse, final FilterChain filterChain)
            throws IOException, ServletException
    {
        final HttpServletRequest request = (HttpServletRequest) servletRequest;
        final HttpServletResponse response = (HttpServletResponse) servletResponse;
        final HttpSession session = request.getSession(false);
        final Assertion assertion = session != null ? (Assertion) session.getAttribute(CONST_CAS_ASSERTION)
                : null;
        
        if (assertion != null)
        {
            filterChain.doFilter(request, response);
            return;
        }
        final String serviceUrl = constructServiceUrl(request, response);
        final String ticket = CommonUtils.safeGetParameter(request,
                getArtifactParameterName());
        final boolean wasGatewayed = this.gatewayStorage.hasGatewayedAlready(request,
                serviceUrl);
        
        // 由于本次已经可以取到cas service返回的新的service ticket
        if (CommonUtils.isNotBlank(ticket) || wasGatewayed)
        {
            // 所以直接进入本代码块,然后退出
            filterChain.doFilter(request, response);
            return;
        }
        // 不会再一次被重定向会cas 认证中心

        final String modifiedServiceUrl;
        
        log.debug("no ticket and no assertion found");
        if (this.gateway)
        {
            log.debug("setting gateway attribute in session");
            modifiedServiceUrl = this.gatewayStorage.storeGatewayInformation(request,
                    serviceUrl);
        }
        else
        {
            modifiedServiceUrl = serviceUrl;
        }
        
        if (log.isDebugEnabled())
        {
            log.debug("Constructed service url: " + modifiedServiceUrl);
        }
        
        // 如果用户没有登录过,那么构造重定向的URL
        final String urlToRedirectTo = CommonUtils.constructRedirectUrl(this.casServerLoginUrl,
                getServiceParameterName(),
                modifiedServiceUrl,
                this.renew,
                this.gateway);
        
        if (log.isDebugEnabled())
        {
            log.debug("redirecting to \"" + urlToRedirectTo + "\"");
        }
        
        // 重定向跳转到Cas认证中心
        response.sendRedirect(urlToRedirectTo);
    }

之后,又会被web.xml中的CAS Validation Filter(Cas20ProxyReceivingTicketValidationFilter)所拦截

该拦截器用来与CAS Server 进行身份核实,以确保 Service Ticket 的合法性

由于 Cas20ProxyReceivingTicketValidationFilter 没有重写doFilter方法,所以会进入父类AbstractTicketValidationFilter的doFilter方法

AbstractTicketValidationFilter.doFilter

 public final void doFilter(final ServletRequest servletRequest,
            final ServletResponse servletResponse, final FilterChain filterChain)
            throws IOException, ServletException
    {
        
        if (!preFilter(servletRequest, servletResponse, filterChain))
        {
            return;
        }
        
        final HttpServletRequest request = (HttpServletRequest) servletRequest;
        final HttpServletResponse response = (HttpServletResponse) servletResponse;
        final String ticket = CommonUtils.safeGetParameter(request,
                getArtifactParameterName());
        
        if (CommonUtils.isNotBlank(ticket))
        {
            if (log.isDebugEnabled())
            {
                log.debug("Attempting to validate ticket: " + ticket);
            }
            
            try
            {
                // 构造验证URL,向cas server发起验证请求
                final Assertion assertion = this.ticketValidator.validate(ticket,
                        constructServiceUrl(request, response));
                
                if (log.isDebugEnabled())
                {
                    log.debug("Successfully authenticated user: "
                            + assertion.getPrincipal().getName());
                }
                
                // 如果验证成功,设置assertion,当再一次发起访问请求时,如果发现assertion已经被设置,所以已经通过验证,不过再次重定向会cas认证中心
                request.setAttribute(CONST_CAS_ASSERTION, assertion);
                
                if (this.useSession)
                {
                    request.getSession().setAttribute(CONST_CAS_ASSERTION,
                            assertion);
                }
                onSuccessfulValidation(request, response, assertion);
                
                if (this.redirectAfterValidation)
                {
                    log.debug("Redirecting after successful ticket validation.");
                    response.sendRedirect(constructServiceUrl(request, response));
                    return;
                }
            }
            catch (final TicketValidationException e)
            {
                response.setStatus(HttpServletResponse.SC_FORBIDDEN);
                log.warn(e, e);
                
                onFailedValidation(request, response);
                
                if (this.exceptionOnValidationFailure)
                {
                    throw new ServletException(e);
                }
                
                return;
            }
        }
        
        filterChain.doFilter(request, response);
        
    }
this.ticketValidator.validate(..) 代码如下
 public Assertion validate(final String ticket, final String service)
            throws TicketValidationException
    {
        
        // 生成验证URL,如果你debug会发现,此处会构造一个类似以下的URL,访问的是cas server的serviceValidate方法
        // https://demo.testcas.com/cas/serviceValidate?ticket=ST-31-cioaDNxSpUWIgeYEn4yK-cas&service=http%3A%2F%2Fapp1.testcas.com%2Fb2c-haohai-server%2Fuser%2FcasLogin
        final String validationUrl = constructValidationUrl(ticket, service);
        if (log.isDebugEnabled())
        {
            log.debug("Constructing validation url: " + validationUrl);
        }
        
        try
        {
            log.debug("Retrieving response from server.");
            // 得到cas service响应,验证成功或者失败
            final String serverResponse = retrieveResponseFromServer(new URL(
                    validationUrl), ticket);
            
            if (serverResponse == null)
            {
                throw new TicketValidationException(
                        "The CAS server returned no response.");
            }
            
            if (log.isDebugEnabled())
            {
                log.debug("Server response: " + serverResponse);
            }
            
            return parseResponseFromServer(serverResponse);
        }
        catch (final MalformedURLException e)
        {
            throw new TicketValidationException(e);
        }
    }
可以看一下,cas server侧的serverValidate的具体实现
在cas server的cas-servlet.xml中,可以看到如下配置:
    <bean
        id="handlerMappingC"
        class="org.springframework.web.servlet.handler.SimpleUrlHandlerMapping">
        <property
            name="mappings">
            <props>
                <prop
                    key="/logout">
                    logoutController
                </prop>
                <prop
                    key="/serviceValidate">
                    serviceValidateController
                </prop>
     ...
指向serviceValidateController

ServiceValidateController.handleRequestInternal(...)
 protected final ModelAndView handleRequestInternal(final HttpServletRequest request, final HttpServletResponse response) throws Exception {
        final WebApplicationService service = this.argumentExtractor.extractService(request);
        final String serviceTicketId = service != null ? service.getArtifactId() : null;

        if (service == null || serviceTicketId == null) {
            if (logger.isDebugEnabled()) {
                logger.debug(String.format("Could not process request; Service: %s, Service Ticket Id: %s", service, serviceTicketId));
            }
            return generateErrorView("INVALID_REQUEST", "INVALID_REQUEST", null);
        }

        try {
            final Credentials serviceCredentials = getServiceCredentialsFromRequest(request);
            String proxyGrantingTicketId = null;

            // XXX should be able to validate AND THEN use
            if (serviceCredentials != null) {
                try {
                    proxyGrantingTicketId = this.centralAuthenticationService
                        .delegateTicketGrantingTicket(serviceTicketId,
                            serviceCredentials);
                } catch (final TicketException e) {
                    logger.error("TicketException generating ticket for: "
                        + serviceCredentials, e);
                }
            }

            final Assertion assertion = this.centralAuthenticationService.validateServiceTicket(serviceTicketId, service);

            final ValidationSpecification validationSpecification = this.getCommandClass();
            final ServletRequestDataBinder binder = new ServletRequestDataBinder(validationSpecification, "validationSpecification");
            initBinder(request, binder);
            binder.bind(request);

            if (!validationSpecification.isSatisfiedBy(assertion)) {
                if (logger.isDebugEnabled()) {
                    logger.debug("ServiceTicket [" + serviceTicketId + "] does not satisfy validation specification.");
                }
                return generateErrorView("INVALID_TICKET", "INVALID_TICKET_SPEC", null);
            }

            onSuccessfulValidation(serviceTicketId, assertion);

            final ModelAndView success = new ModelAndView(this.successView);
            success.addObject(MODEL_ASSERTION, assertion);

            if (serviceCredentials != null && proxyGrantingTicketId != null) {
                final String proxyIou = this.proxyHandler.handle(serviceCredentials, proxyGrantingTicketId);
                success.addObject(MODEL_PROXY_GRANTING_TICKET_IOU, proxyIou);
            }

            if (logger.isDebugEnabled()) {
                logger.debug(String.format("Successfully validated service ticket: %s", serviceTicketId));
            }

            return success;
        } catch (final TicketValidationException e) {
            return generateErrorView(e.getCode(), e.getCode(), new Object[] {serviceTicketId, e.getOriginalService().getId(), service.getId()});
        } catch (final TicketException te) {
            return generateErrorView(te.getCode(), te.getCode(),
                new Object[] {serviceTicketId});
        } catch (final UnauthorizedServiceException e) {
            return generateErrorView(e.getMessage(), e.getMessage(), null);
        }
    }
验证成功后,就可以正常访问了。

来源:https://www.cnblogs.com/notDog/p/5252973.html

CAS3.5.2 Server 集成 OAuth2.0 Server 详细介绍

OAuth2.0是一个开放标准,允许用户让第三方应用访问该用户在某一网站上存储用户信息,而无需将用户名和密码提供给第三方应用,CAS3.5.x(x>1)提供了OAuth2.0的支持,包括客户端和服务端,依赖cas-server-support-oauth.jar包。

基本工作过程如下:

OAuth 2.0 Authorization

Jakob Jenkov
Last update: 2014-06-15

When a client applications wants access to the resources of a resource owner, hosted on a resource server, the client application must first obtain an authorization grant. This text explains how such an application grant is obtained.

Client ID, Client Secret and Redirect URI

Before a client application can request access to resources on a resource server, the client application must first register with the authorization server associated with the resource server.

The registration is typically a one-time task. Once registered, the registration remains valid, unless the client app registration is revoked.

At registration the client application is assigned a client ID and a client secret (password) by the authorization server. The client ID and secret is unique to the client application on that authorization server. If a client application registers with multiple authorization servers (e.g. both Facebook, Twitter and Google), each authorization server will issue its own unique client ID to the client application.

Whenever the client application requests access to resources stored on that same resource server, the client application needs to authenticate itself by sending along the client ID and the client secret to the autorhization server.

During the registration the client also registers a redirect URI. This redirect URI is used when a resource owner grants authorization to the client application. When a resource owner has successfully authorized the client application via the authorization server, the resource owner is redirected back to the client application, to the redirect URI.

Authorization Grant

The authorization grant is given to a client application by the resource owner, in cooperation with the authorization server associated with the resource server.

The OAuth 2.0 specification lists four different types of authorization grants. Each type has different security characteristics. The authorization grant types are:

  • Authorization Code
  • Implicit
  • Resource Owner Password Credentials
  • Client Credentials

Each of these authorization grant types is covered in the following sections.

Authorization Code

An authorization grant using an authorization code works like this (the numbers correspond to the steps shown in the diagram below the description):

1) The resource owner (user) accesses the client application.

2) The client application tells the user to login to the client application via an authorization server (e.g. Facebook, Twitter, Google etc.).

3) To login via the authorizaion server, the user is redirected to the authorization server by the client application. The client application sends its client ID along to the authorization server, so the authorization server knows which application is trying to access the protected resources.

4) The user logs in via the authorization server. After successful login the user is asked if she wants to grant access to her resources to the client application. If the user accepts, the user is redirected back to the client application.

5) When redirected back to the client application, the authorization server sends the user to a specific redirect URI, which the client application has registered with the authorization server ahead of time. Along with the redirection, the authorization server sends an authorization code, representing the authorization.

6) When the redirect URI in the client application is accessed, the client application connects directly to the authorization server. The client application sends the authorization code along with its own client ID and and client secret.

7) If the authorization server can accept these values, the authorization server sends back an access token.

10) The client application can now use the access token to request resources from the resource server. The access token serves as both authentication of the client, resource owner (user) and authorization to access the resources.

Here is a diagram illustrating the authorization process when using authorization code to authorize a client application:

1
Authorization grant via authorization code.

Implicit

An implicit authorization grant is similar to an authorization code grant, except the access token is returned to the client application already after the user has finished the authorization. The access token is thus returned when the user agent is redirected to the redirect URI.

This of course means that the access token is accessible in the user agent, or native application participating in the implicit authorization grant. The access token is not stored securely on a web server.

Furthermore, the client application can only send its client ID to the authorization server. If the client were to send its client secret too, the client secret would have to be stored in the user agent or native application too. That would make it vulnerable to hacking.

Implicit authorization grant is mostly used in a user agent or native client application. The user agent or native application would receive the access token from the authorization server.

Here is an illustration of implicit authorization grant:

2
Implicit authorization grant.

Resource Owner Password Credentials

The resource owner password credentials authorization grant method works by giving the client application access to the resource owners credentials. For instance, a user could type his Twitter user name and password (credentials) into the client application. The client application could then use the user name and password to access resources in Twitter.

Using the resource owner password credentials requires a lot of trust in the client application. You do not want to type your credentials into an application you suspect might abuse it.

The resource owner password credentials would normally be used by user agent client applications, or native client applications.

Client Credentials

Client credential authorization is for the situations where the client application needs to access resources or call functions in the resource server, which are not related to a specific resource owner (e.g. user). For instance, obtaining a list of venues from Foursquare. This does not necessary have anything to do with a specific Foursquare user.

cas 3.5.2下载地址:https://github.com/apereo/cas/releases/tag/v3.5.2

CAS默认提供了三个服务:

/oauth2.0/authorize

需要输入GET参数:client_id和redirect_uri

/oauth2.0/accessToken

需要输入GET参数:client_idredirect_uriclient_secret和代码

/oauth2.0/profile

需要输入GET参数:access_token

关于CAS3.5.x Server版本接入oauth2.0 Server配置步骤,下面为本站素文宅www.yoodb.com大家分享一下个人总结,仅供大家参考学习使用。

1、将cas-server-support-oauth工程引入cas-server-webapp项目中,通过pom.xml文件,增加内容如下:

<dependency>
<groupId>org.jasig.cas</groupId>
<artifactId>cas-server-support-oauth</artifactId>
<version>${project.version}</version>
</dependency>

2、配置应用获得client_id和client_secret

在QQ、新浪等使用第三方登录中,通常提供页面供用户申请应用,然后提供用户client_id和client_secret,并允许用户配置回调地址,那么oauth2.0 server考虑的就是需要持久化这些配置,CAS默认在文件deployerConfigContext.xml的serviceRegistryDao中配置应用服务,注意实际使用可以将申请的应用信息存储在数据库中,具体配置如下:

<bean
id="serviceRegistryDao"
        class="org.jasig.cas.services.InMemoryServiceRegistryDaoImpl">
            <property name="registeredServices">
                <list>
                    <bean class="org.jasig.cas.services.RegexRegisteredService">
                        <property name="id" value="0" />
                        <property name="name" value="HTTP and IMAP" />
                        <property name="description" value="Allows HTTP(S) and IMAP(S) protocols" />
                        <property name="serviceId" value="^(https?|imaps?)://.*" />
                        <property name="evaluationOrder" value="10000001" />
<!-- 参数回传 -->
                        <property name="ignoreAttributes" value="true"/>
                    </bean>
                    <bean class="org.jasig.cas.services.RegisteredServiceImpl">
                    <property name="id" value="1" />
                    <property name="name" value="HTTP" />
                    <property name="description" value="oauth wrapper callback url" /><!-- oauth wrapper callback url -->
                    <property name="serviceId" value="${server.prefix}/oauth2.0/callbackAuthorize" />
                </bean>
               <bean class="org.jasig.cas.services.RegisteredServiceImpl">
                <property name="id" value="2" />
                <property name="name" value="key" />
                <property name="description" value="secret" />
                <property name="serviceId" value="http://www.yoodb.com/" />
                <property name="theme" value="Yoodb" />
              </bean>
                </list>
            </property>
        </bean>

如上述代码所示,新注册了两个bean,第一个bean不需要考虑那是默认存在的bean,如果想了解参考地址:bean http://blog.yoodb.com/yoodb/article/detail/1223,我们新增的第二个bean中,name为client_id,description为client_secret,serviceId为回调地址,theme为应用名称,下面为大家说说第一个bean的用法及其用途。

3、 Oauth client构造url获得authorization_code(ST票据)

1)cas server对/oauth2.0/authorize的url进行拦截处理,需要配置映射,在web.xml中增加配置信息如下:

<servlet-mapping>
    <servlet-name>cas</servlet-name>
    <url-pattern>/oauth2.0/*</url-pattern>
</servlet-mapping>

2)在cas-servlet.xml配置文件,增加内容如下:

<bean
      id="handlerMappingC"
      class="org.springframework.web.servlet.handler.SimpleUrlHandlerMapping">
    <property name="mappings">
      <props>
...
...
<prop key="/oauth2.0/*">oauth20WrapperController</prop>
...
...
<props>
</bean>
<bean id="oauth20WrapperController"
    class="org.jasig.cas.support.oauth.web.OAuth20WrapperController"
    p:loginUrl="${server.prefix}/login" p:servicesManager-ref="servicesManager"
    p:ticketRegistry-ref="ticketRegistry" p:timeout="7200" />

配置完成后,我们获取授权码的链接会转向login页面,此时的service地址就是第二步时新增的bean配置的第一个bean的serviceId,通过这个默认提供的地址间接的获取到ST票据,具体请求如下:

CAS Server在浏览器中打开地址:

http://localhost:8080/cas/oauth2.0/authorize?client_id=key&redirect_uri=http://www.yoodb.com/&response_type=codea

将会跳转到地址:

http://localhost:8080/cas/login?service=http%3A%2F%2F127.0.0.1%3A8080%2Fcas%2Foauth2.0%2FcallbackAuthorize

,从而间接的获取到ST票据。认证成功之后,就会携带值为ST票据的参数跳转到callbackAuthorize页面,此时生成的ST即为授权码,其中回调地址、服务名称是通过session传递过来的,注意到浏览器地址变为如下:

http://localhost:8080/cas/oauth2.0/callbackAuthorize?ticket=ST-5-u53bEqNQz2phBhnocFsb-www.yoodb.com

默认授权码只能使用一次且有效时间为10s,可以参考http://blog.yoodb.com/yoodb/article/detail/1225文章,通过修改票据过期策略进行配置时间。

4、通过ST票据授权码获得access_token

在浏览器中输入如下地址:

http://localhost:8080/cas/oauth2.0/accessToken?client_id=key&client_secret=secret&
grant_type=authorization_code&redirect_uri=http://www.yoodb.com/&code=ST-3-KIxamZyWgOYFcoXggdfs-www.yoodb.com

返回access_token信息如下:

access_token=TGT-6-csg7B16Pc09aZ6bx9j3Y6INMzScyZFhZcOGEqpnBUvoiLJkv93-www.yoodb.com&expires=7193

5、根据access_token获取用户信息

在浏览器中输入如下地址:

http://localhost:8080/cas/oauth2.0/cas/oauth2.0/profile?access_token=TGT-4-bxgrfir4tdCJ2O1EbR6eeguc3tcdpToZeyFBv416vdvvH1g3Nk-www.yoodb.com

根据access_token等到的返回用户信息如下:

{
    "id": "000000000000000001",
    "attributes": [
        {
            "uid": "000000000000000001"
        },
        {
            "username": "mrwang"
        },
        {
            "password": "123456"
        }
    ]
}

通过上述描述CAS3.5.x Server认证成功之后生成ST,此值即为授权码,传递给应用的回调地址即可,OAuth2的实现并不是很标准,对于CAS3.5.x Server版本需要扩展org.jasig.cas.support.oauth.web.OAuth20WrapperController类来进一步完善oauth2.0协议。

本站文章除注明转载外,均由 素文宅 整理发布,欢迎任何形式的转载,但请务必注明出处。

转载请注明:文章转载自 素文宅博客

本文标题:CAS3.5.2 Server 集成 OAuth2.0 Server 详细介绍

本文地址:https://blog.yoodb.com/yoodb/article/detail/1226

什么是JWT(JSON WEB TOKEN)

     Json web token(JWT)是为了网络应用环境间传递声明而执行的一种基于JSON的开发标准(RFC 7519),该token被设计为紧凑且安全的,特别适用于分布式站点的单点登陆(SSO)场景。JWT的声明一般被用来在身份提供者和服务提供者间传递被认证的用户身份信息,以便于从资源服务器获取资源,也可以增加一些额外的其它业务逻辑所必须的声明信息,该token也可直接被用于认证,也可被加密。

  起源

说起JWT,我们应该来谈一谈基于token的认证和传统的Session认证的区别。

  传统的session认证

我们知道,http协议本身是一种无状态的协议,而这就意味着如果用户向我们的应用提供了用户名和密码来进行用户认证,那么下一次请求时,用户还要再一次进行用户认证才行,因为根据http协议,我们并不能知道是哪个用户发送的请求,所以为了让我们的应用能识别是哪个用户发出的,我们只能在服务器存储一份用户登陆的信息,这份登陆信息会在响应时传递给服务器,告诉其保存为cookie,以便下次请求时发送给我们的应用,这样我们的英哟个就能识别请求来自哪个用户了,这就是传统的基于sessino认证

但是这种基于session的认证使应用本身很难得扩展,随着不用客户端的增加,独立的服务器已无法承载更多的用户,而这个时候基于session认证应用的问题就会暴露出来

  基于session认证所显露的问题

Session:每个用户经过我们的应用认证之后,我们的应用都要在服务端做一次记录,以便用户下次请求的鉴别,通常而言session都是保存在内存中,而随着认证用户的增多,服务端的开销会明显增大

扩展性:用户认证之后,服务端做认证记录,如果认证的记录被保存在内存的话,这意味着用户下次请求还必须要请求在这台服务器上,这样才能拿到授权的资源,这样在分布式的应用上,响应的限制了负载均衡器的能力,也意味着限制了应用的扩展性

CSRF:因为是基于cookie来进行用户识别的,cookie如果被截获,用户就会很容易受到跨站请求伪造的攻击。

基于token的鉴权机制

基于token的鉴权机制类似于http协议也是无状态的,它不需要在服务端去保留用户的认证信息或会话信息。这也就意味着机遇tokent认证机制的应用不需要去考虑用户在哪一台服务器登陆了,这就为应用的扩展提供了便利

流程是这样的

  • 用户使用用户名密码请求服务器
  • 服务器进行验证用户信息
  • 服务器通过验证发送给用户一个token
  • 客户端存储token,并在每次请求时附加这个token值
  • 服务器验证token,并返回数据

这个token必须要在每次请求时发送给服务器,它应该保存在请求头中,另外,服务器要支持CORS(跨来源资源共享)策略,一般我们在服务端这么做就可以了 Access-Control-Allow-Origin:*

JWT的构成

JWT是由三部分构成,将这三段信息文本用链接构成了JWT字符串。就像这样

eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJVc2VySWQiOjEyMywiVXNlck5hbWUiOiJhZG1pbiJ9.Qjw1epD5P6p4Yy2yju3-fkq28PddznqRj3ESfALQy_U

第一部分我们称它为头部(header)第二部分我们称其为载荷(payload,类似于飞机上承载的物品),第三部分是签证(signature)

   header

JWT的头部承载的两部分信息:

  • 声明类型,这里是jwt
  • 声明加密的算法,通常直接使用HMAC SHA256

完整的头部就像下面这样的JSON

{
     'typ':'JWT',
     'alg':'HS256'  
}

然后将头部进行base64加密(该加密是可以对称解密的),构成了第一部分

eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9

    plyload

载荷就是存放有效信息的地方。这个名字像是特指飞机上承载的货品,这些有效信息包含三个部分

  • 标准中注册的声明
  • 公共的声明
  • 私有的声明

标注中注册的声明(建议不强制使用)

  • iss:jwt签发者
  • sub:jwt所面向的用户
  • aud:接收jwt的一方
  • exp:jwt的过期时间,这个过期时间必须大于签发时间
  • nbf:定义在什么时间之前,该jwt都是不可用的
  • iat:jwt的签发时间
  • jti:jwt的唯一身份标识,主要用来作为一次性token,从而回避重放攻击

公共的声明:

公共的声明可以添加任何的信息,一般添加用户的相关信息或其它业务需要的必要信息,但不建议添加敏感信息,因为该部分在客户端可解密;

私有的声明

私有的声明是提供者和消费者功能定义的声明,一般不建议存放敏感信息,因为base64是对称解密的,意味着该部分信息可以归类为名文信息。

定义一个payload

{
  "sub": "1234567890",
  "name": "John Doe",
  "admin": true
}

然后将其base64加密,得到jwt的一部分

eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9

Signature

jwt的第三部分是一个签证信息,这个签证信息由三部分组成:

  • header(base64后的)
  • payload(base64后的)
  • secred

这个部分需要base64加密后的header和base64加密后的payload使用“.”连接组成的字符串,然后通过header中声明的加密方式进行加secret组合加密,然后就构成了jwt的第三部分

 

var encodedString = base64UrlEncode(header) + '.' + base64UrlEncode(payload);
var signature = HMACSHA256(encodedString, 'secret'); // TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ

将这三部分用“.”连接成一个完整的字符串,构成了最终的jwt:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ

注意:secret是保存在服务器端的,jwt的签发也是在服务端的,secret就是用来进行jwt的签发和jwt的验证,所以它就是你服务端的私钥,在任何场景都不应该流露出去,一旦客户端得知这个secret,那就意味着客户端可以自我签发jwt了

应用

一般是在请求头里加入Authorization,并加上Bearer标注:

fetch('api/user/1', {
  headers: {
    'Authorization': 'Bearer ' + token
  }
})

服务端会验证token,如果验证通过就会返回相应的资源,整个流程就是这样

总结

优点:

  • 因为json的通用性,所以JWT是可以跨语言支持的,像C#,JavaScript,NodeJS,PHP等许多语言都可以使用
  • 因为由了payload部分,所以JWT可以在自身存储一些其它业务逻辑所必要的非敏感信息
  • 便于传输,jwt的构成非常简单,字节占用很小,所以它是非常便于传输的
  • 它不需要在服务端保存会话信息,所以它易于应用的扩展

安全相关

  • 不应该在jwt的payload部分存储敏感信息,因为该部分是客户端可解密的部分
  • 保护好secret私钥。该私钥非常重要
  • 如果可以,请使用https协议

转自于:http://www.jianshu.com/p/576dbf44b2ae

CAS 跨域原理

CAS(Central Authentication Service) 是 Yale 大学发起的一个开源项目,据统计,大概每 10 个采用开源构建 Web SSO 的 Java 项目,就有 8 个使用 CAS 。对这些统计,我虽然不以为然,但有一点可以肯定的是, CAS 是我认为最简单实效,而且足够安全的 SSO 选择。

本节主要分析 CAS 的安全性,以及为什么 CAS 被这样设计,带着少许密码学的基础知识,我希望有助于读者对 CAS 的协议有更深层次的理解。
从结构体系看, CAS 包含两部分:
l         CAS Server
CAS Server 负责完成对用户的认证工作, CAS Server 需要独立部署,有不止一种 CAS Server 的实现, Yale CAS Server 和 ESUP CAS Server 都是很不错的选择。
CAS Server 会处理用户名 / 密码等凭证 (Credentials) ,它可能会到数据库检索一条用户帐号信息,也可能在 XML 文件中检索用户密码,对这种方式, CAS 均提供一种灵活但同一的接口 / 实现分离的方式, CAS 究竟是用何种认证方式,跟 CAS 协议是分离的,也就是,这个认证的实现细节可以自己定制和扩展。
l         CAS Client
CAS Client 负责部署在客户端(注意,我是指 Web 应用),原则上, CAS Client 的部署意味着,当有对本地 Web 应用的受保护资源的访问请求,并且需要对请求方进行身份认证, Web 应用不再接受任何的用户名密码等类似的 Credentials ,而是重定向到 CAS Server 进行认证。
目前, CAS Client 支持(某些在完善中)非常多的客户端,包括 Java 、 .Net 、 ISAPI 、 Php 、 Perl 、 uPortal 、 Acegi 、 Ruby 、 VBScript 等客户端,几乎可以这样说, CAS 协议能够适合任何语言编写的客户端应用。

 剖析协议就像剖析设计模式,有些时候,协议让人摸不着头脑。 CAS 的代理模式要相对复杂一些,它引入了一些新的概念,我希望能够在这里描述一下其原理,有助于读者在配置和调试 CAS SSO 有更清晰的思路。

如果没记错, CAS 协议应该是由 Drew Mazurek 负责可开发的,从 CAS v1 到现在的 CAS v3 ,整个协议的基础思想都是基于 Kerberos 的票据方式。
       CAS v1 非常原始,传送一个用户名居然是 ”yes david.turing” 的方式, CAS v2 开始使用了 XML 规范,大大增强了可扩展性, CAS v3 开始使用 AOP 技术,让 Spring 爱好者可以轻松配置 CAS Server 到现有的应用环境中。
CAS 是通过 TGT(Ticket Granting Ticket) 来获取 ST(Service Ticket) ,通过 ST 来访问服务,而 CAS 也有对应 TGT , ST 的实体,而且他们在保护 TGT 的方法上虽然有所区别,但是,最终都可以实现这样一个目的——免去多次登录的麻烦。
       下面,我们看看 CAS 的基本协议框架:
       上图是一个最基础的 CAS 协议, CAS Client 以 Filter 方式保护 Web 应用的受保护资源,过滤从客户端过来的每一个 Web 请求,同时, CAS Client 会分析 HTTP 请求中是否包请求 Service Ticket( 上图中的 Ticket) ,如果没有,则说明该用户是没有经过认证的,于是, CAS Client 会重定向用户请求到 CAS Server ( Step 2 )。 Step 3 是用户认证过程,如果用户提供了正确的 Credentials , CAS Server 会产生一个随机的 Service Ticket ,然后,缓存该 Ticket ,并且重定向用户到 CAS Client (附带刚才产生的 Service Ticket ), Service Ticket 是不可以伪造的,最后, Step 5 和 Step6 是 CAS Client 和 CAS Server 之间完成了一个对用户的身份核实,用 Ticket 查到 Username ,因为 Ticket 是 CAS Server 产生的,因此,所以 CAS Server 的判断是毋庸置疑的。
       该协议完成了一个很简单的任务,就是 User(david.turing) 打开 IE ,直接访问 helloservice 应用,它被立即重定向到 CAS Server 进行认证, User 可能感觉到浏览器在 helloservcie 和 casserver 之间重定向,但 User 是看不到, CAS Client 和 CAS Server 相互间的 Service Ticket 核实 (Validation) 过程。当 CAS Server 告知 CAS Client 用户 Service Ticket 对应确凿身份, CAS Client 才会对当前 Request 的用户进行服务。

CAS 如何实现 SSO

       当我们的 Web 时代还处于初级阶段的时候, SSO 是通过共享 cookies 来实现,比如,下面三个域名要做 SSO :
http://www.blogjava.net
http://www.matrix.org.cn
http://www.csdn.net
如果通过 CAS 来集成这三个应用,那么,这三个域名都要做一些域名映射,
http://blogjava.cas.org
http://matrix.cas.org
http://csdn.cas.org
因为是同一个域,所以每个站点都能够共享基于 cas.org 的 cookies 。这种方法原始,不灵活而且有不少安全隐患,已经被抛弃了。
CAS 可以很简单的实现跨域的 SSO ,因为,单点被控制在 CAS Server ,用户最有价值的 TGC-Cookie 只是跟 CAS Server 相关, CAS Server 就只有一个,因此,解决了 cookies 不能跨域的问题。
回到 CAS 的基础协议图,当 Step3 完成之后, CAS Server 会向 User 发送一个 Ticket granting cookie (TGC) 给 User 的浏览器,这个 Cookie 就类似 Kerberos 的 TGT ,下次当用户被 Helloservice2 重定向到 CAS Server 的时候, CAS Server 会主动 Get 到这个 TGC cookie ,然后做下面的事情:
1,              如果 User 的持有 TGC 且其还没失效,那么就走基础协议图的 Step4 ,达到了 SSO 的效果。
2,              如果 TGC 失效,那么用户还是要重新认证 ( 走基础协议图的 Step3) 。
 CAS 的代理模式

 模式 1 已经能够满足大部分简单的 SSO 应用,现在,我们探讨一种更复杂的情况,即用户访问 helloservice , helloservice 又依赖于 helloservice2 来获取一些信息,如同:

User à helloservice à helloservice2
这种情况下,假设 helloservice2 也是需要对 User 进行身份验证才能访问,那么,为了不影响用户体验(过多的重定向导致 User 的 IE 窗口不停地 闪动 ) , CAS 引入了一种 Proxy 认证机制,即 CAS Client 可以代理用户去访问其它 Web 应用。
代理的前提是需要 CAS Client 拥有用户的身份信息 ( 类似凭据 ) 。 与其说之前我们提到的 TGC 是用户持有对自己身份信息的一种凭据,则这里的 PGT 就是 CAS Client 端持有的对用户身份信息的一种凭据。凭借 TGC , User 可以免去输入密码以获取访问其它服务的 Service Ticket ,所以,这里,凭借 PGT , Web 应用可以代理用户去实现后端的认证,而无需前端用户的参与。
如下面的 CAS Proxy 图所示, CAS Client 在基础协议之上,提供了一个额外的 PGT URL 给 CAS Server, 于是, CAS Server 可以通过 PGT URL 提供一个 PGT 给 CAS Client 。
初学者可能会对上图的 PGT URL 感到迷惑,或者会问,为什么要这么麻烦,要通过一个额外的 URL( 而且是 SSL 的入口 ) 去传递 PGT ?如果直接在 Step 6 返回,则连用来做对应关系的 PGTIOU 都可以省掉。 PGTIOU 设计是从安全性考虑的,非常必要, CAS 协议安全性问题我会在后面一节介绍。
于是, CAS Client 拿到了 PGT( PGTIOU-85…..ti2td ) ,这个 PGT 跟 TGC 同样地关键, CAS Client 可以通过 PGT 向后端 Web 应用进行认证。如下图所示, Proxy 认证与普通的认证其实差别不大, Step1, 2 与基础模式的 Step 1,2 几乎一样,唯一不同的是, Proxy 模式用的是 PGT 而不是 TGC ,是 Proxy Ticket ( PT )而不是 Service Ticket 。
最终的结果是, helloservice2 明白 helloservice 所代理的客户是 David. Turing 同学,同时,根据本地策略, helloservice2 有义务为 PGTURL=http://helloservice/proxy 服务 (PGTURL 用于表示一个 Proxy 服务 ) ,于是它传递数据给 helloservice 。这样, helloservice 便完成一个代理者的角色,协助 User 返回他想要的数据。
代理认证模式非常有用,它也是 CAS 协议 v2 的一个最大的变化,这种模式非常适合在复杂的业务领域中应用 SSO 。因为,以前我们实施 SSO 的时候,都是假定以 IE User 为 SSO 的访问者,忽视了业务系统作为 SSO 的访问者角色。
作者:木木
出处:http://haore147.cnblogs.com/
博客文章大部分为原创,版权归作者和博客园共有,欢迎转载。

搭建基于OAuth2和SSO的开放平台

开放平台介绍

什么是开放平台

开放平台在百科中的定义:
开放平台(Open Platform) 在软件行业和网络中,开放平台是指软件系统通过公开其应用程序编程接口(API)或函数(function)来使外部的程序可以增加该软件系统的功能或使用该软件系统的资源,而不需要更改该软件系统的源代码。

通俗或者说应景点的说法,开放平台,就是互联网企业,将其内部的资源(一般是数据),比如用户数据,平台业务数据,以技术的手段(一般是RESTFul接口API),开放给受控的第三方合作伙伴,活公司内部的其它一些产品,形成一个安全受控的资源暴露平台。

为什么要搭建开放平台

搭建开放平台的意义,一般在于:
1.搭建基于API的生态体系
2.利用开放平台,搭建基于计费的API数据平台
3.为APP端提供统一接口管控平台,类似于网关的概念
4.为第三方合作伙伴的业务对接提供授信可控的技术对接平台

开放平台体系结构图

open

开放平台核心模块

一个典型的开放平台,至少包含以下几个核心模块:
1.平台门户
平台门户负责向第三方展示用于进行业务及技术集成的管理界面,至少包含以下几个功能:
1.服务商入住(第三方合作伙伴入住)
2.应用配置(第三方应用管理)
3.权限申请(一般包括接口权限和字段权限)
4.运维中心(开放平台当前服务器、接口状态,服务商接口告警等)
5.帮助中心(入住流程说明,快速接入说明,API文档等)

2.鉴权服务
鉴权服务负责整个平台的安全性
1.接口调用鉴权(第三方合作伙伴是否有权限调用某接口)
2.用户授权管理(用户对某个第三方应用获取改用户信息的权限管理)
3.用户鉴权(平台用户的鉴权)
4.应用鉴权(第三方合作伙伴的应用是否有权调用该平台)

3.开放接口
开放接口用于将平台数据暴露给合作伙伴
1.平台用户接口(用于获取公司APP生态链中的用户信息)
2.平台数据接口(平台中的一些开放数据)
3.其它业务接口(平台开放的一些业务数据)

4.运营系统
运营系统是整个平台的后台业务管理系统,负责对第三方合作伙伴提出的各种申请进行审核操作,对当前应用的操作进行审计工作,对当前业务健康度进行监控等
1.服务商管理(对第三方合作伙伴的资质进行审核、操作)
2.应用管理(对第三方应用进行审核、上下线管理)
3.权限管理(对合作伙伴申请的资源进行审核、操作)
4.统计分析(监控平台当前运行状态,统计平台业务数据)

OAuth2介绍

什么是OAuth2

百科:OAUTH协议为用户资源的授权提供了一个安全的、开放而又简易的标准。与以往的授权方式不同之处是OAUTH的授权不会使第三方触及到用户的帐号信息(如用户名与密码),即第三方无需使用用户的用户名与密码就可以申请获得该用户资源的授权,因此OAUTH是安全的。oAuth是Open Authorization的简写。

简单来说:OAuth2协议,定义了一套用户、第三方服务和存储着用户数据的平台之间的交互规则,可以使得用户无需将自己的用户名和密码暴露给第三方,即可使第三方应用获取用户在该平台上的数据,最常见的场景便是现在互联网上的各种使用XXX账号登录。

OAuth2协议中角色介绍

OAuth2协议中,共有四个参与方(角色):
1.resource owner:资源拥有者
即用户
2.resource server:资源服务器
即存储用户数据的服务器,一般对外都以RESTFul API的形式暴露用户数据,client使用access token访问resource server申请被保护起来的用户数据
3.client:客户端
即第三方应用
4.authorization server:授权服务器
用来鉴权第三方应用合法性,并对用户登录、是否授权第三方应用获取数据进行响应,并根据用户操作,想第三应用颁发用户token或者告知授权失败

OAuth2常用协议介绍

OAUTH2标准业务协议,如下图所示
oauth
A.第三方应用向用户请求授权,希望获取用户数据
B.用户同意授权
C.第三方应用拿着用户授权,向平台索要用户access token
D.平台校验第三应用合法性及用户授权真实性后,向平台发放用户access token
E.第三方应用拿着用户access token向平台索要用户数据
F.平台在校验用户access token真实性后,返回用户数据

 

各个角色之间的关系,可以通过国外网站介绍了解一下, 如下

OAuth 2.0 defines the following roles of users and applications:

  • Resource Owner
  • Resource Server
  • Client Application
  • Authorization Server

These roles are illustrated in this diagram:

OAuth 2.0 roles as defined in the specification.

The resource owner is the person or application that owns the data that is to be shared. For instance, a user on Facebook or Google could be a resource owner. The resource they own is their data. The resource owner is depicted in the diagram as a person, which is probably the most common situation. The resource owner could also be an application. The OAuth 2.0 specification mentions both possibilities.

The resource server is the server hosting the resources. For instance, Facebook or Google is a resource server (or has a resource server).

The client application is the application requesting access to the resources stored on the resource server. The resources, which are owned by the resource owner. A client application could be a game requesting access to a users Facebook account.

The authorization server is the server authorizing the client app to access the resources of the resource owner. The authorization server and the resource server can be the same server, but it doesn’t have to. The OAuth 2.0 specification does not say anything about how these two servers should communicate, if they are separate. This is an internal design decision to be made by the resource server + authorization server developers.

上述内容来源:http://tutorials.jenkov.com/oauth2/roles.html

OAuth2使用场景介绍

目前,OAuth2协议使用最多的场景还是用以给第三方应用获取用户信息,业务流程如下图所示
case
1.在浏览器中,用户点击第三方应用按钮,由第三方应用发起请求,向平台发起授权请求。
2.平台在接收到第三方应用请求后,浏览器跳转用户登录界面,请求用户进行登录。
3.用户在平台登录界面输入用户名、密码进行登录
4.平台判断用户合法性,校验失败,在浏览器中提示错误原因
5.平台判断用户是否需要对该第三方应用进行授权。(不需要授权的情况有两种:a.平台信任该第三方应用,如公司内部应用,无需用户进行授权,默认给予用户数据。b.该用户之前已经给该应用授予过权限,并且仍在有效期内)
6.如需授权,平台跳转浏览器界面至授权界面,告知用户将授予哪个第三方哪些数据权限
7.用户授权后,将用户授权码回调给第三方url
8.第三方在获取用户授权码后,带着用户授权码访问平台鉴权接口,请求用户token
9.平台在收到第三方请求后,校验授权码真实性,并返回用户token
10.第三方使用用户token向平台请求用户接口
11.平台接口判断用户token真实性,并向第三方返回用户数据

OAuth2核心功能说明

1.应用注册
应用注册后,OAuth2会下发应用app_id和app_secret,用以标记该应用的唯一性,并且这两个参数将贯穿整个OAuth协议,用以对应用合法性进行校验。同时,应用需要提供redirect_uri,用以和平台进行异步交互,获取用户令牌及错误信息。
2.授权/鉴权中心
a.对用户的应户名、密码进行鉴权
b.对第三方应用的app_id,app_secret进行鉴权
c.展示授权界面,并对用户对第三方应用的授权操作进行响应
d.对用户授权码及用户token的真实性进行鉴权
3.token管理
a.创建token、刷新token
b.查询token详细数据
c.校验token时效性

OAuth2体系结构

case

开放平台集成OAuth2体系

1.平台门户:
门户应用入住界面,需要集成OAuth2应用创建接口,录入第三方回调地址,并回显app_id和app_secret参数
2.鉴权服务:
鉴权服务需集成OAuth2的authorize及token接口,用以提供用户授权及code/token鉴权功能
3.开放接口:
开放接口需集成OAuth2的resource server角色,对用户数据进行安全管理,对第三方应用发起的请求做出响应,并对token进行真实性校验
4.运营系统:
运营系统需提供对当前OAuth2应用的管理功能,用户授权列表管理,用户token管理等OAuth2协议相关管理功能。

另外, oauth2.0 有很多类型, 如下

OAuth 2.0 Client Types

Jakob Jenkov
Last update: 2014-06-15

The OAuth 2.0 client role is subdivided into a set of client types and profiles. This text will explain these types and profiles.

The OAuth 2.0 specification defines two types of clients:

  • Confidential
  • Public

A confidential client is an application that is capable of keeping a client password confidential to the world. This client password is assigned to the client app by the authorization server. This password is used to identify the client to the authorization server, to avoid fraud. An example of a confidential client could be a web app, where no one but the administrator can get access to the server, and see the client password.

A public client is an application that is not capable of keeping a client password confidential. For instance, a mobile phone application or a desktop application that has the client password embedded inside it. Such an application could get cracked, and this could reveal the password. The same is true for a JavaScript application running in the users browser. The user could use a JavaScript debugger to look into the application, and see the client password.

Client Profiles

The OAuth 2.0 specification also mentions a set of client profiles. These profiles are concrete types of applications, that can be either confidential or public. The profiles are:

  • Web Application
  • User Agent
  • Native

Web Application

A web application is an application running on a web server. In reality, a web application typically consists of both a browser part and a server part. If a web application needs access to a resource server (e.g. to Facebook user accounts), then the client password could be stored on the server. The password would thus be confidential.

Here is an illustration of a confidential client web application:

Confidential client: Web Application.

User Agent Application

A user agent application is for instance a JavaScript application running in a browser. The browser is the user agent. A user agent application may be stored on a web server, but the application is only running in the user agent once downloaded. An example could be a little JavaScript game that only runs in the browser.

Here is an illustration of a client user agent application:

Public client: User Agent Application.

Native Application

A native application is for instance a desktop application or a mobile phone application. Native applications are typically installed on the users computer or device (phone, tablet etc.). Thus, the client password will be stored on the users computer or device too.

Here is an illustration of a client native application:

Public client: Native Application.

 

Hybrid Applications

Some applications are hybrids of these profiles. For instance, a native application can have a server part too, that does part of the work (e.g. store data). The OAuth 2.0 specification says nothing about such hybrids. However, in most cases a hybrid will be able to use the authentication models of one of these profiles.

上述资料内容来源: http://tutorials.jenkov.com/oauth2/client-types.html

SSO介绍

什么是SSO

百科:SSO英文全称Single Sign On,单点登录。SSO是在多个应用系统中,用户只需要登录一次就可以访问所有相互信任的应用系统。它包括可以将这次主要的登录映射到其他应用中用于同一个用户的登录的机制。它是目前比较流行的企业业务整合的解决方案之一。

简单来说,SSO出现的目的在于解决同一产品体系中,多应用共享用户session的需求。SSO通过将用户登录信息映射到浏览器cookie中,解决其它应用免登获取用户session的问题。

为什么需要SSO

开放平台业务本身不需要SSO,但是如果平台的普通用户也可以在申请后成为一个应用开发者,那么就需要将平台加入到公司的整体账号体系中去,另外,对于企业级场景来说,一般都会有SSO系统,充当统一的账号校验入口。

CAS协议中概念介绍

SSO单点登录只是一个方案,而目前市面上最流行的单端登录系统是由耶鲁大学开发的CAS系统,而由其实现的CAS协议,也成为目前SSO协议中的既定协议,下文中的单点登录协议及结构,均为CAS中的体现结构
CAS协议中有以下几个概念:
1.CAS Client:需要集成单点登录的应用,称为单点登录客户端
2.CAS Server:单点登录服务器,用户登录鉴权、凭证下发及校验等操作
3.TGT:ticker granting ticket,用户凭证票据,用以标记用户凭证,用户在单点登录系统中登录一次后,再其有效期内,TGT即代表用户凭证,用户在其它client中无需再进行二次登录操作,即可共享单点登录系统中的已登录用户信息
4.ST:service ticket,服务票据,服务可以理解为客户端应用的一个业务模块,体现为客户端回调url,CAS用以进行服务权限校验,即CAS可以对接入的客户端进行管控
5.TGC:ticket granting cookie,存储用户票据的cookie,即用户登录凭证最终映射的cookies

CAS核心协议介绍

case
1.用户在浏览器中访问应用
2.应用发现需要索要用户信息,跳转至SSO服务器
3.SSO服务器向用户展示登录界面,用户进行登录操作,SSO服务器进行用户校验后,映射出TGC
4.SSO服务器向回调应用服务url,返回ST
5.应用去SSO服务器校验ST权限及合法性
6.SSO服务器校验成功后,返回用户信息

CAS基本流程介绍

以下为基本的CAS协议流程,图一为初次登录时的流程,图二为已进行过一次登录后的流程
case
case

代码及示例

spring提供了整套的开源包,用以搭建OAUTH2+SSO的体系:
1.spring-oauth2:用以实现OAuth2协议,提供了上述所有四个角色提供的功能
2.spring-cas:用以实现和cas的集成,将OAuth2的登录、登出功能委托给CAS处理,并提供了统一的回调机制及凭证校验机制
3.CAS,耶鲁大学官方提供的SSO开源实现,本文的单点登录协议即按照CAS进行的说明

本文还提供了基于GO语言实现的简单OAuth2+SSO功能,详见github:

https://github.com/janwenjohn/go-oauth2-sso

原创文章,转载或摘录请说明文章来源:http://heartlifes.com

-----

下面是一个很好的 关于cas的 文章再录如下:

对的,PORTAL里一定含有SSO,在此先提一下。

下面是一些著名的调查公司显示的统计数据:

  • 用户每天平均16分钟花在身份验证任务上 - 资料来源:IDS
  • 频繁的IT用户平均有21个密码 - 资料来源:NTA Monitor Password Survey
  • 49%的人写下了其密码,而67%的人很少改变它们
  • 每79秒出现一起身份被窃事件 - 资料来源:National Small Business Travel Assoc
  • 全球欺骗损失每年约12B - 资料来源:Comm Fraud Control Assoc

使用“单点登录”整合后,只需要登录一次就可以进入多个系统,而不需要重新登录,这不仅仅带来了更好的用户体验,更重要的是降低了安全的风险和管理的消耗。

请看下面的统计数据:

  • 提高IT效率:对于每1000个受管用户,每用户可节省$70K
  • 帮助台呼叫减少至少1/3,对于10K员工的公司,每年可以节省每用户$75,或者合计$648K
  • 生产力提高:每个新员工可节省$1K,每个老员工可节省$350 - 资料来源:Giga
  • ROI回报:7.5到13个月 - 资料来源:Gartner

另外,使用“单点登录”还是SOA时代的需求之一。在面向服务的架构中,服务和服务之间,程序和程序之间的通讯大量存在,服务之间的安全认证是SOA应用的难点之一,应此建立“单点登录”的系统体系能够大大简化SOA的安全问题,提高服务之间的合作效率。

以下是一个标准的企业内通过SSO来集成各个系统间的认证与权限的模型图

好了,以上基本知识普及完毕开始我们的SSO实现。

CAS SSO

SSO实现有很多产品,我们今天选用的这个是耶鲁大学发明的CAS SSO服务器。这个CAS SSO是目前我看到过的功能较全的,使用也是最简单的配置式SSO服务器,它基于SPRING的原理,因此这个配置文件我们看起来因当是相当的熟悉的。

它分为Server版和Client版2个模块,同时它对于一些其它功能特性如:数据库、LDAP协议(就是WINDOWS AD域使用的协议)、安全等还提供了一系列的插件。因此,在本例中,我使用的是:

请严格按照我的版本号进行试验。

什么叫Server端 ,什么叫Client端?

看上图,假设我们有3个War包。
  • 一个叫cas-server.war,它放在tomcat里;
  • 一个叫cas-sample-site1.war,它放在jboss里;
  • 一个叫cas-sample-site2.war,它放在jboss里;
那么位于tomcat里的cas-server.war,它就是我们的CAS的Server端,位于jboss里的两个war就是我们CAS的client端。
SSO中的Server端与Client端概念搞清后,我们现在就开始布署吧。

布署cas-server

先说一下我们的环境:
版本号 web端口
tomcat69090
jboss78080
我们把Server端解压得到以下这样的一个文件夹

它里面含了一堆的东西,关键在于以下这个文件夹

进入该文件夹,找到这样一个war包。

把这个war包解压后重命名成cas-server.war,放于tomcat的webapp目录中去,启动tomcat一切无误后即可。

然后我们打开一个ie,输入http://localhost:9090/cas-server会得到以下这个界面,那就说明你的cas sso已经安装成功了。

配置CAS SERVER

添加依赖包

在本例中我们将使用Oracle数据库中自建一个用户表来管理我们的用户名和密码,因此:

  1. 将oracle的ojdbc6.jar放入tomcat的lib目录内D:\tomcat\lib
  2. 将cas-server-3.5.2-release\cas-server-3.5.2\modules下的这几个文件拷入tomcat\webapp\cas-server\web-inf\lib目录内

修改配置文件

CAS SSO的好处在于它的配置文件是完全spring的,你只要懂spring就可以非常容易的在里面去添加修改自己的一些功能,我们在第一天的教程中为了尽量简单,我们只需要改动一个文件,它就是:

tomcat\webapps\cas-server\WEB-INF目录下的

deployerConfigContext.xml文件

我们用纯文件编辑器打开它,找到下面这行:<bean  class="org.jasig.cas.authentication.handler.support.SimpleTestUsernamePasswordAuthenticationHandler" />
把它注释掉

<!-- 
<bean class="org.jasig.cas.authentication.handler.support.SimpleTestUsernamePasswordAuthenticationHandler" /> 
-->  
然后再在它下面添加如下内容
<!-- 
   <bean class="org.jasig.cas.authentication.handler.support.SimpleTestUsernamePasswordAuthenticationHandler" /> 
-->  
<bean class="org.jasig.cas.adaptors.jdbc.QueryDatabaseAuthenticationHandler">  
      <property name="dataSource" ref="dataSource" ></property>  
      <property name="sql" value="select password from sys_user where user_id=?" ></property>  
</bean>

好,这边我们看到了一个dataSource对吧,EASY,来。。。

<!-- 
          <bean class="org.jasig.cas.authentication.handler.support.SimpleTestUsernamePasswordAuthenticationHandler" /> 
-->  
          <bean class="org.jasig.cas.adaptors.jdbc.QueryDatabaseAuthenticationHandler">  
            <property name="dataSource" ref="dataSource" ></property>  
            <property name="sql" value="select password from sys_user where user_id=?" ></property>  
          </bean>  
    </list>  
</property>  
</bean>  
  
<bean id="dataSource"  
    class="org.springframework.jdbc.datasource.DriverManagerDataSource">  
    <property name="driverClassName" value="oracle.jdbc.OracleDriver" />  
    <property name="url" value="jdbc:oracle:thin:@localhost:1521:orcl" />  
    <property name="username" value="ymk" />  
    <property name="password" value="password_1" />  
</bean>

注意我加的这个dataSource的bean和刚才那段配置代码之间的位置对应关系哦,别胡乱搞一个回车就乱加一行哦。

全加完了,怎么样啦?完成了吗?

还没,CAS SSO严格意义上来说需要J2EE APP SERVER里实现HTTPSSSL的双向认证模式才能正常使用,但是我们因为这个是教程,因此不想搞了太麻烦,我们可以在“不使用HTTPS认证”的情况下也可以使用CAS SSO。

为此,我们要关闭CAS SSO的HTTPS认证模式,编辑:

tomcat\webapps\cas-server\WEB-INF\spring-configuration目录下的

ticketGrantingTicketCookieGenerator.xml文件

找到下面这行

  1. <bean id="ticketGrantingTicketCookieGenerator" class="org.jasig.cas.web.support.CookieRetrievingCookieGenerator"
  2.     p:cookieSecure="true"
  3.     p:cookieMaxAge="-1"
  4.     p:cookieName="CASTGC"
  5.     p:cookiePath="/cas" />
  6. </beans>

把这边的p:cookieSecure从true改为false即可。

然后我们在oracle中建一个用户表吧,建表语句如下:

  1. CREATE TABLE SYS_USER
  2. (
  3.     "USER_ID" VARCHAR2(16),
  4.     "PASSWORD" VARCHAR2(8),
  5.      CONSTRAINT "PK_SYS_USER" PRIMARY KEY ("USER_ID")
  6. );

该表中含有一条记录:

这就是我们的用于测试的单点登录的用户名和密码了,很简单吧?

全部保存后,重启tomcat,一切无误,然后我们打开一个ie,输入http://localhost:9090/cas-server会得到以下这个界面,那就说明你的cas sso已经安装成功了。

我们在用户名中输入sso, 在密码一栏中输入aaaaaa,然后看到下面这个界面,即代表我们的cas server和我们的数据库已经完全连上了。

如果我们不按照sys_user表中的用户名和密码就随意输入用户名和密码,那我们便会得到这样的结果:

将不同的工程连接上cas server以实现单点登录

按照这个图,我们将会有2个不同的war包

  • 一个叫cas-sample-site1.war,它放在jboss里;
  • 一个叫cas-sample-site2.war,它放在jboss里;

我们在我们的eclipse里创建两个这样的war工程即可,这是非常简单的事,这2个工程都含有一个index.jsp文件。

cas-sample-site1

在它的index.jsp文件中含有如下内容:

  1. <%@ page language="java" contentType="text/html; charset=utf-8"
  2.     pageEncoding="utf-8"%>
  3. <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
  4. <html>
  5. <head>
  6. <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  7. <title>cas sample site1</title>
  8. </head>
  9. <body>
  10. <h1>cas sample site1</h1>
  11. <a href="http://localhost:8080/cas-sample-site2/index.jsp">cas-sample-site2</a>
  12. </br>
  13. <a href="http://localhost:9090/cas-server/logout">退出</a>
  14. </body>
  15. </html>

cas-sample-site2

在它的index.jsp文件中含有如下内容:

  1. <%@ page language="java" contentType="text/html; charset=utf-8"
  2.     pageEncoding="utf-8"%>
  3. <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
  4. <html>
  5. <head>
  6. <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  7. <title>cas sample site2</title>
  8. </head>
  9. <body>
  10. <h1>cas sample site2</h1>
  11. <a href="http://localhost:8080/cas-sample-site1/index.jsp">cas-sample-site1</a>
  12. </br>
  13. <a href="http://localhost:9090/cas-server/logout">退出</a>
  14. </body>
  15. </html>

这两个war工程都有一个lib目录,确保它们的lib目录里都有这样几个jar

look, 注意要有cas-client-core-3.2.1.jar哦,它来自于:cas-client-3.2.1-release\cas-client-3.2.1\modulescas-client-3.2.1-release.zip解压出来的内容。

 

这两个工程的web.xml可以说是完全一模一样,我们来看:

<?xml version="1.0" encoding="UTF-8"?>  
<web-app xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://java.sun.com/xml/ns/javaee" xmlns:web="http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd" xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd" id="WebApp_ID" version="2.5">  
  <display-name>cas-sample-site2</display-name>  
  <welcome-file-list>  
    <welcome-file>index.jsp</welcome-file>  
    <welcome-file>index.html</welcome-file>  
    <welcome-file>index.htm</welcome-file>      
    <welcome-file>default.html</welcome-file>  
    <welcome-file>default.htm</welcome-file>  
    <welcome-file>default.jsp</welcome-file>  
  </welcome-file-list>  
   <listener>  
        <listener-class>org.jasig.cas.client.session.SingleSignOutHttpSessionListener</listener-class>  
  </listener>  
      
  <filter>  
        <filter-name>CAS Single Sign Out Filter</filter-name>  
        <filter-class>org.jasig.cas.client.session.SingleSignOutFilter</filter-class>  
  </filter>  
  <filter-mapping>  
        <filter-name>CAS Single Sign Out Filter</filter-name>  
        <url-pattern>*</url-pattern>  
  </filter-mapping>  
  
  <filter>  
        <filter-name>CAS Validation Filter</filter-name>  
        <filter-class>org.jasig.cas.client.validation.Cas20ProxyReceivingTicketValidationFilter</filter-class>  
        <init-param>  
            <param-name>casServerUrlPrefix</param-name>  
            <param-value>http://localhost:9090/cas-server</param-value>  
        </init-param>  
        <init-param>  
            <param-name>serverName</param-name>  
            <param-value>http://localhost:8080</param-value>  
        </init-param>  
        <init-param>  
            <param-name>useSession</param-name>  
            <param-value>true</param-value>  
        </init-param>  
        <init-param>  
            <param-name>redirectAfterValidation</param-name>  
            <param-value>true</param-value>  
        </init-param>  
  </filter>  
  <filter-mapping>  
        <filter-name>CAS Validation Filter</filter-name>  
        <url-pattern>*</url-pattern>  
  </filter-mapping>  
  
  <filter>  
        <filter-name>CAS Filter</filter-name>  
        <filter-class>org.jasig.cas.client.authentication.AuthenticationFilter</filter-class>  
        <init-param>  
            <param-name>casServerLoginUrl</param-name>  
            <param-value>http://localhost:9090/cas-server/login</param-value>  
        </init-param>  
        <init-param>  
            <param-name>serverName</param-name>  
            <param-value>http://localhost:8080</param-value>  
        </init-param>  
  </filter>  
  <filter-mapping>  
        <filter-name>CAS Filter</filter-name>  
        <url-pattern>*</url-pattern>  
  </filter-mapping>  
  
  <filter>  
        <filter-name>CAS HttpServletRequest Wrapper Filter</filter-name>  
        <filter-class>org.jasig.cas.client.util.HttpServletRequestWrapperFilter</filter-class>  
  </filter>  
  <filter-mapping>  
        <filter-name>CAS HttpServletRequest Wrapper Filter</filter-name>  
        <url-pattern>*</url-pattern>  
  </filter-mapping>  
</web-app>

看到了没有,有这么一堆的listener和filter,而且它们一个不能漏,并且它们的顺序也是绝对不能够错的,一定要按照下面这个从上至下的顺序:

org.jasig.cas.client.session.SingleSignOutHttpSessionListener
org.jasig.cas.client.session.SingleSignOutFilter
org.jasig.cas.client.validation.Cas20ProxyReceivingTicketValidationFilter
org.jasig.cas.client.authentication.AuthenticationFilter
org.jasig.cas.client.util.HttpServletRequestWrapperFilter
漏了一个,或者顺序错了,你将会发生下列情况:

  1. 可以正常登录,无法统一注销,即然是单点登录,那么我在任意一个站点上点“注销“是不是也因该是统一注销啊?
  2. 可以登录,可以统一注销,但是拿不到cas-server上登录的用户的user session,如果我们是两个系统,那么这两个系统是不是都有web sesssion?较常用的就是user session,那么如果你的顺序配错了,或者是你漏配了一个,你是得不到cas-server上传过来的用户的一些登录信息的,这个很糟糕,这将会为我们后面的编程开发带来烦恼
  3. 不能登录
至于为什么会得到这样的一些结果?
嘿嘿!
我们在后面的课程中会来分析cas 单点登录的源码(这个过程一点不变态,很简单的,一说就通,跟着我的教程一步步走不难的),在深入源码中后你就可以看出为什么这几个东西它们有严格意义上的顺序的关系了。
在这个web.xml文件里我们可以看到有两处出现了下面的这样的东西:
<init-param>  
        <param-name>casServerUrlPrefix</param-name>  
        <param-value>http://localhost:9090/cas-server</param-value>  
</init-param>  
<init-param>  
        <param-name>serverName</param-name>  
        <param-value>http://localhost:8080</param-value>  
</init-param>

记住,上面的那行代表我们的cas server的服务器所在的地址,当用户用上面的cas-server的登录界面登录成功后,cas server 会自动跳回用户在ie地址里输入的子系统地址的首页。

如:我们先输入http://localhost:8080/cas-sample-site1,此时系统会先跳到http://localhost:9090/cas-server/login的画面要求用户先去做一次登录。

那么cas server它是怎么知道子系统地址的首页位于哪个地址(哪台服务器上)的呢,那么你要”注册“这个地址给cas server。

因此,第二行就是我们的具体的子系统的首页所在的地址。

这样的地方在我们的web.xml文件中一共出现了两处:

  • 一处位于org.jasig.cas.client.validation.Cas20ProxyReceivingTicketValidationFilter
  • 一处位于org.jasig.cas.client.authentication.AuthenticationFilter
这2处如果没配好,你会遇到下列问题:
  • 登录后无法正常跳回子系统的首页
  • 无法正常退出
  • 无法做系统间切换时的跳转
因此一定要注意啦!!!

我们把两个工程通过ECLIPSE布署在JBOSS7上,然后运行起来吧。

别忘了启动我们的Tomcat里的cas server哦。

全部启动完毕后我们在IE浏览器里输入:http://localhost:8080/cas-sample-site1 

此时浏览器显示如下画面

我们在cas server的登录画面输入我们数据库表sys_user中的相应的用户名与密码后,再来看此时的浏览器它会跑到哪儿去?

点击cas-sample-site2这个链接呢?

然后点击“退出”这个链接

此时我们再在浏览器里输入:http://localhost:8080/cas-sample-site2--有时浏览器有缓存,它还是会显示cas-sample-site2的首页,这时你可以点一下F5或者是刷新按钮(这个可以通过代码来避免jsp或者是html页中使用缓存来做到)

look!

由于是统一注销,因此一旦注销,两个WEB都无法访问了,必须要求“统一登录一下”,于是我们再次输入用户名和密码

来源: https://blog.csdn.net/u012891504/article/details/52472818