Hi, I implemented a SAMLTokenValidator using the org.apache.rahas.TokenValidatorinterface. I am returning a SOAP envelope containing a Status token with the Code set to either valid or invalid, according to the WS-Trust specification [1]. Below you find a sample request and response (the headers and the saml assertion on the request are omitted):
-> request: <wst:RequestSecurityToken xmlns:wst=" http://schemas.xmlsoap.org/ws/2005/02/trust "> <wst:RequestType> http://schemas.xmlsoap.org/ws/2005/02/trust/Validate </wst:RequestType> <wst:TokenType>http://schemas.xmlsoap.org/ws/2005/02/trust/RSTR/Status </wst:TokenType> </wst:RequestSecurityToken> -> response (for a valid token): <wst:RequestSecurityTokenResponse xmlns:wst="http://schemas.xmlsoap.org/ws/2005/02/trust "> <wst:TokenType> http://schemas.xmlsoap.org/ws/2005/02/trust/RSTR/Status </wst:TokenType> <wst:Status> <wst:Code>http://schemas.xmlsoap.org/ws/2005/02/trust/status/valid </wst:Code> </wst:Status> </wst:RequestSecurityTokenResponse> Basically my implementation of TokenValidator.validate(RahasData arg) verifies the signature on the SAML assertion extracted from the validate request message using openSAML [2]. Since the token is signed by the issuer in a RSTR/Issue message, for a RST/Validate I verify it using the Issuer's PublicKey. My questions now are: 1.) Is it enough to just verify the Issuer's signature to state the token is valid? I've taken this approach as recommended in [3]: 2.) Should I take into consideration the effective policy (extracted from the current inflow MessageContext)? P.S.: I did not implement support for configuration files, elements and so on (similar to the mechanisms used in SAMLTokenIssuerConfig, and TokenCancelerConfig). To retrieve the Issuer's certificates, I am just reusing the configuration in place for the TokenIssuer. [1] - http://specs.xmlsoap.org/ws/2005/02/trust/WS-Trust.pdf [2] - SAMLAssertion.verify(java.security.Key arg) [3] - http://msdn2.microsoft.com/en-us/library/aa480563.aspx#wss_ch1_brokauthsts_topic4 Thanks and regards, Joana On 12/21/07, Joana M. F. Trindade <[EMAIL PROTECTED] > wrote: > > Hi Nandana, > > I created a JiRA for this issue. In my case, I think I'm also affected by > the lack of support to " validation" and "renewal" of issued tokens, so I > voted on this one :-) > > Thanks and regards, > Joana Trindade > > On Dec 21, 2007 10:16 AM, Nandana Mihindukulasooriya < > [EMAIL PROTECTED]> wrote: > > > Hi, > > > > Are you referring to the code in org.apache.rahas.TokenRequestDispatcher > > ? > > > > > > > > > No, I was actually referring to > > org.apache.rampart.PolicyBasedResultsValidator. > > When the request comes to the service , this class checks whether the > > security > > requirements and constraints of service's security policy is met in the > > message. > > > > > > > After sending the initial email I saw that when the type of request is > > > either "validate" or "renew", the dispatcher throws an > > > UnsupportedOperationException. Should I refer to this on the JiRA? > > > > > > > > There is already a JIRA created for this. see [1]. > > > > Thanks, > > Nandana > > > > [1] - http://issues.apache.org/jira/browse/RAMPART-87 > > > > > > > > > > > > > > > Thanks and regards, > > > Joana > > > > > > On Dec 21, 2007 5:38 AM, Nandana Mihindukulasooriya < > > [EMAIL PROTECTED] > > > > > > > wrote: > > > > > > > Hi, > > > > > > > > In our case here, we would like our trusted services to only respond > > to > > > > > requests that contain a valid SAML Token issued by the STS. On the > > > > > > > samples, > > > > > it doesn't seem to make any difference on the service response > > whether > > > i > > > > > add > > > > > the token to the request or not. > > > > > > > > > > > > If I understand correctly, you have a Issued token as a supporting > > > token > > > > in > > > > the > > > > service policy. When I went through the code, that there is a > > problem in > > > > validating > > > > the supporting tokens according to the given policy in Rampart. BTW, > > > this > > > > not > > > > specific to SAML Tokens, all supporting tokens suffer from this > > problem. > > > > This should be > > > > fixed in Rampart. Please go on and create a JiRA in Rampart. > > > > > > > > Thanks, > > > > Nandana > > > > > > > > > > > > > > > > -- > > > Student Intern > > > SAP Research - Security & Trust > > > SAP Labs France > > > > > > 805 Avenue du Dr. Maurice Donat > > > 06250 Mougins > > > T +33/492286319 > > > F +33/492286201 > > > > > Personal Homepage: > > > http://www.inf.ufrgs.br/~jmftrindade<http://www.inf.ufrgs.br/%7Ejmftrindade> > > <http://www.inf.ufrgs.br/%7Ejmftrindade> > > > > > > > > > -- > Student Intern > SAP Research - Security & Trust > SAP Labs France > > 805 Avenue du Dr. Maurice Donat > 06250 Mougins > T +33/492286319 > F +33/492286201 > Personal Homepage: http://www.inf.ufrgs.br/~jmftrindade > -- Student Intern SAP Research - Security & Trust SAP Labs France 805 Avenue du Dr. Maurice Donat 06250 Mougins T +33/492286319 F +33/492286201 Personal Homepage: http://www.inf.ufrgs.br/~jmftrindade
