Mailing-List: contact users-help@cxf.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@cxf.apache.org
Received-SPF: softfail (athena.apache.org: transitioning domain of
 asharma@talend.com does not designate 83.246.65.53 as permitted sender)
From: Anubhav Sharma <asharma@talend.com>
To: Daniel Kulp <dkulp@apache.org>, "users@cxf.apache.org"
	<users@cxf.apache.org>
Date: Fri, 11 Mar 2011 17:26:56 +0100
Subject: Re: STS Provider Contribution
Thread-Topic: STS Provider Contribution
Thread-Index: AcveA7LPCGODuYRSQSiA3vHoShFSfgCBXBiC
Message-ID: <C9A00BE0.4B63%anubhav.sharma@sopera.de>
In-Reply-To: <201103082142.49546.dkulp@apache.org>
Accept-Language: en-US
Content-Language: en
acceptlanguage: en-US
Content-Type: multipart/alternative;
	boundary="_000_C9A00BE04B63anubhavsharmasoperade_"
MIME-Version: 1.0

--_000_C9A00BE04B63anubhavsharmasoperade_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


Hi Dan,

Thanks for your inputs. I have cleaned up the code and attached a new versi=
on of the STS provider to the JIRA issue.
I have incorporated your inputs regarding DOMSource and JAXB, you are right=
, it is much simpler that way.
I still need to check for the code generation issue.

Thanks and Cheers,
Anubhav

On 3/9/11 3:42 AM, "Daniel Kulp" <dkulp@apache.org> wrote:


This is definitely a good start.  As you said, the code needs some major
cleanup which does make it a bit harder to really review.

My initial 2-minute thoughts:

Code generation issues:
1) We really need to generate the code into org.apache.cxf namespace
someplace.   A jaxb binding file would take care of that.

2) Also, do we really need to generate for things like the xmldsig and poli=
cy
namespaces?   Seems a bit strange to me.


Runtime:
The provider is marked PAYLOAD and DOMSource.   Thus, the DOM just contains
the contents of the SOAP Body.  However, the first thing you do is convert =
to
a SOAPMessage.   Why?   I don't see the point in that and I think it's wron=
g
as the envelop and  body  wouldn't be there.

I'd recommend switching to just Source (instead of DOMSource).  You can the=
n
return a JAXBSource object and eliminate the entire JAXB -> DOM step in the=
re.
It's a little trickier on the incoming side, but not by a lot.   Most likel=
y,
I would just take the original incoming Source and feed it directly into JA=
XB
to unmarshal, and then grab the RequestType out of the JAXB object.  (or fr=
om
the ws-a Action header that could be injected in via the WebServiceContext)=
.

Anyway, definitely a good start.

Dan


On Tuesday 08 March 2011 10:05:19 AM Anubhav Sharma wrote:
> Hi All,
>
> I have attached an initial implementation of the STS provider framework a=
nd
> the Issue operation. The eclipse project is attached to the following
> Jira:
> https://issues.apache.org/jira/browse/CXF-1940
>
> I still need to refractor the code with regards to logging, exception
> tracing, checkstyles etc. I would request you all to provide an initial
> feedback while I proceed with the code cleanup.
>
> Thanks!
> Anubhav
>
>
> On 2/23/11 1:46 PM, "Anubhav Sharma" <asharma@talend.com> wrote:
>
>
>
>
> Hello Everyone,
>
> I would like to contribute an STS provider framework to the CXF project.
> The idea would be to implement a provider based STS service, the obvious
> reason being that it can support both WS Trust 1.3 and 1.4 versions. The
> invoke method of this provider would convert the request into
> corresponding JAXB objects and delegate the call to the right
> implementation. The implementation of operations like Issue, Renew etc.
> would be configured in spring. The users would just need to implement
> their business logic for these operations and configure the implementatio=
n
> class  in spring.
>
> As an example I would also like to contribute a sample implementation for
> the Issue operation. This sample would accept UsernameToken and X509Token
> as inputs, use local file system for authentication and return back a SAM=
L
> Token. I would propose to support both, SAML 1.1 and SAML 2.0. In the RST=
,
> user can use TokenType attribute to request either a SAML 1.1 or 2.0
> token.
>
> This would give the CXF users an opportunity to use and test the sts clie=
nt
> against the sample STS implementation, extend the STS with their business
> implementations and in future we can enhance STS with a more sophisticate=
d
> and complete implementation.
>
> Would appreciate your views and inputs on this.
>
> Cheers,
> Anubhav

--
Daniel Kulp
dkulp@apache.org
http://dankulp.com/blog
Talend - http://www.talend.com


--_000_C9A00BE04B63anubhavsharmasoperade_--