Hi Joana,
> 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]. Great. Can you create a patch and attach it to the JIRA issue so that you can contribute the source to the community. > 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]: I also think this will be enough. But I think we should go through the SAML token profile - [1] too to be on the safe side. If SAML v1.1 token is to be validated, What about the <saml:Conditions NotBefore="XXX" NotOnOrAfter="XXX"/>. Do we have to take it in to consideration too when we returning the token validity ? > 2.) Should I take into consideration the effective policy (extracted from > the current inflow MessageContext)? IFAIK, nope. Rampart handlers will validate the security of incoming messages according to the effective policy of the STS and fail if the security constraints and requirements are not met. So I don't think you will have to think about the effective policy of the message. Thanks, Nandana [1] - www.oasis-open.org/committees/download.php/16768/wss-v*1.1*-spec-os-* SAML**Token**Profile*.pdf > > [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> > > > < 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<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<http://www.inf.ufrgs.br/%7Ejmftrindade> >
