cxf-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Oliver Wulff (JIRA)" <>
Subject [jira] [Commented] (FEDIZ-72) Make Trusted IDP protocol customizable
Date Thu, 06 Mar 2014 09:14:42 GMT


Oliver Wulff commented on FEDIZ-72:

Got a pluggable version running locally... will commit soon.

Some slight changes to the interfaces:

public interface ProtocolHandler {
    String getProtocol();

public interface TrustedIdpProtocolHandler extends ProtocolHandler {
    boolean canHandleRequest(HttpServletRequest request);

    // Only supports HTTP GET SignIn Requests
    URL mapSignInRequest(RequestContext context, Idp idp, TrustedIdp trustedIdp);
    //Hook in <action-state id="validateToken"> of federation-signin-response.xml
    SecurityToken mapSignInResponse(RequestContext context, Idp idp, TrustedIdp trustedIdp);

It's also planned to support custom application protocols which extends ProtocolHandler also.

> Make Trusted IDP protocol customizable
> --------------------------------------
>                 Key: FEDIZ-72
>                 URL:
>             Project: CXF-Fediz
>          Issue Type: Improvement
>          Components: IDP
>    Affects Versions: 1.1.0
>            Reporter: Oliver Wulff
>            Assignee: Oliver Wulff
> In release 1.1, the Fediz IDP doesn't support other protocols than WS-Federation for
a Trusted IDP. Due to the usage of Spring Web Flow, the flow can still be customized but it
has a bigger impact and later migration to new release require more effort.
> This is a proposal to add support for custom protocols for Trusted IDPs:
> - Introduce Interface "SSOProtocolBridge" which is able to transform a WS-Federation
SignIn Request to another SignIn Request (ex. SAML-P AuthRequest) and to transform another
SignIn Response (ex. SAML-P AuthResponse) to a WS-Federation SignIn Response.
> - Processing logic is part of the main IDP web flow which chooses a protocol depending
on the configuration of the TrustedIdp
> - New protocol implementations can be found due to spring annotations scanning and injecting
the beans in the core processing logic
> {code}
> public interface SSOProtocolBridge {
>     boolean canHandleRequest(HttpServletRequest request);
>     String getProtocol();
>     // ActionState before redirectToTrustedIDP end-state to define SignIn URL
>     // Note: Only supports HTTP GET SignIn Requests
>     URL mapSignInRequest(RequestContext context);
>     // Hook in <action-state id="validateToken"> of federation-signin-response.xml
>     // ValidateTokenAction class delegates to an implementation of mapSignInResponse()
according to the current protocol in the conversation
>     SecurityToken mapSignInResponse(RequestContext context);
> }
> {code}

This message was sent by Atlassian JIRA

View raw message