Hi Nandana,
Regarding to the last mail:
We are using STS as SAML Authority using RAHAS module and we would need to
tell our customer what can be done for the moment using RAHAS (and what
can´t be done, we don´t want to give too many expectations).
In an scenario where we have the following actors:
A client accessing a WebService, and a SAML Authority (STS):
1) Have the client and the web Service to access to the same SAML
Authority? (I have read anywhere that the SAML Authority only can be of STS
type).
2) Covers RAHAS all the scenarios of SAML interaction between these actors
or there are any limitations currently?
Thanks, Nuria
2008/2/14, Nandana Mihindukulasooriya <[EMAIL PROTECTED]>:
>
> Hi Jens,
> Not at the moment. But we will include a one before next release.
>
> thanks,
> nandana
>
> On Tue, Feb 12, 2008 at 2:31 PM, Jens Goldhammer
> <[EMAIL PROTECTED]> wrote:
> >
> > Hello Nunny,
> >
> > is there any sample available where the SAML token can be used as a
> > protection token for signing and encrypting messages?
> >
> > Thanks,
> > Jens
> >
> >
> >
> >
> >
> > Nunny wrote:
> > >
> > > Hi Nuria,
> > >
> > >> I've some doubts about SAML with axis2. I need to know if the
> sample05
> > >> covers all the the SAML cases.
> > >
> > > No, it covers only one scenario. For example, this uses SAML token as
> a
> > > supporting token. There is another scenarios where SAML token can be
> > > used as a protection token where it will be used to sign and encrypt
> > > messages.
> > >
> > >
> > >
> > >> We first receive the SAML token response then we indicate, in the
> options
> > >> the responseToken id
> > >> I don't know where we are sending to the server the SAML assertion
> in the
> > >> soapMessage
> > >
> > > When the id is set, Rampart message builders add the assertion to the
> > > security
> > > header according to the security policy. If you monitor the messages
> > > exchanged
> > > through TCPMon, then you can actually see the SAML assertion in the
> > > security
> > > header of the SOAP request to the service.
> > >
> > >> Another thing is to know what are the requestSecurityToken
> parameters.
> > >
> > > In the client, we set these parameters using RST template.
> > >
> > > private static OMElement getRSTTemplate() throws Exception {
> > > OMFactory fac = OMAbstractFactory.getOMFactory();
> > > OMElement elem =
> > > fac.createOMElement(SP11Constants.REQUEST_SECURITY_TOKEN_TEMPLATE);
> > > TrustUtil.createTokenTypeElement(RahasConstants.VERSION_05_02,
> > > elem).setText(RahasConstants.TOK_TYPE_SAML_10);
> > > TrustUtil.createKeyTypeElement(RahasConstants.VERSION_05_02,
> elem,
> > > RahasConstants.KEY_TYPE_PUBLIC_KEY);
> > > TrustUtil.createKeySizeElement(RahasConstants.VERSION_05_02,
> elem, 256);
> > > return elem;
> > > }
> > >
> > > These parameters are defined in the WS Trust specification [1].
> > >
> > > /nandana
> > >
> > > [1] - specs.xmlsoap.org/ws/2005/02/trust/WS-Trust.pdf
> > >
> > > http://nandana83.blogspot.com/
> > > http://nandanasm.wordpress.com/
> > >
> >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > For additional commands, e-mail: [EMAIL PROTECTED]
> > >
> > >
> > >
> >
> > --
> > View this message in context:
> http://www.nabble.com/SAML-with-Axis2-tp15314610p15429275.html
> > Sent from the Axis - User mailing list archive at Nabble.com.
> >
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
