Joinup.

Ricardo, with "session object", do you mean attributes parameter of type Map<String, Object>? I suppose these attribues are just a copy of request parameters from URL GET and POST. If I put some object there, would it travel with redirections? Now to the explanation, why I need the HttpServletRequest... In Slovenia we have a couple of identity providers. All are CAs that issue X509 certificates. For Stork we're not going to make any redirections to these IdPs. Instead we are establishing a so called CVS (central validation system), that will handle the authentication on behalf of all the Slovenian IdPs. One part of the system is front end Apache that for the /PEPS/CitizenConsent page requires and checks the SSL client authentication and if the cert is OK, it transfers the client cert data as an http header to PEPS. In our specific PEPS we then extract the eID from cert data and call our attribute provider's web service. We don't need any redirection that PEPS is providing for IdPs and APs, so in specific.properties I put idp.url=https://peps.mju.gov.si/PEPS/SpecificIdPResponse I have not changed the ap.url yet because until last version the redirections didn't go outside PEPS. Probably in this version I would change also the ap.url to return immediately to PEPS. Let me explain where I would need the HttpServletRequest: in authenticateCitizen ---------------------- to get the SSL Certificate that is passed to Tomcat from Apache front end. This is done with request.getHeader("x_ssl_client_cert") to write the eID of the citizen into the *session* attribute. Be careful not to save it as request attribute because it must not be traveling around with redirections that are triggered by the PEPS following the IdPResponse. in getAttributes -------------------- to get the eID from the HTTP session that was put there with the authenticateCitizen above As I understand, the request.setAttribute is not problematic as it can be replaced in the new version with attributes.put, so I can give the error code and text to show in the logs and to the citizen. The other possibility I'm thinking about would be calling the attribute provider immediately from authenticateCitizen and bypass the redirections where PEPS is gathering attributes, so there would be no need to save the userid into session. This would obviate two uses of the HttpServletRequest above. However I'm not sure if it's possible to make a redirection that will take all the attributes successfully to S-PEPS' ColleagueResponse. If this can be done the only question would remain, how to get the x_ssl_client_cert from Apache. Also, such kind of overhauling takes time and that's why I'm not very content with removal of HttpServletRequest from the interface. The schedule is running up. I'm attaching the code of SpecificPEPS.java that I deployed successfully in the previous version of PEPS (from end of December). It's not polished yet, so please refer to it only as a last resource for clarifications. I've not inserted the actual access to our attribute provider's web service yet.

Maks, I will answer your question bellow: > Ricardo, with "session object", do you mean attributes > parameter of type Map<String, Object>? I suppose these > attribues are just a copy of request parameters from URL GET > and POST. The "session" is an object (of type Map<String, Object>) that spring handles like a session. So, whenever you need to write on it, it will be there until the session expires (you can have more info here: http://static.springsource.org/spring/docs/2.5.x/reference/beans.html#be...). >If I put some object there, would it travel with > redirections? I am not sure if I understand you, but e.g. you can put some object there, at CitizenConsentAction class (or any other class invoked by this action) you will be able to get the same object on SpecificIdPResponseAction or SpecificAPResponseAction. >We don't need any redirection that PEPS is providing for IdPs and APs, >so in specific.properties I put >idp.url=https://peps.mju.gov.si/PEPS/SpecificIdPResponse You can change CitizenConsent action on PEPS's struts.xml, in order to redirect to another action.E.g.: <action name="CitizenConsent" class="springManagedConsentTypeAction"> <result name="success" type="redirectAction"> <param name="actionName">SpecificIdPResponse</param> </result> </action> >I have not changed the ap.url yet because until last version > the redirections didn't go outside PEPS. Probably in this version > I would change also the ap.url to return immediately to PEPS. The communication between CPEPS and AP or IdP is a reference, so you can simply modify/remove them. If you wish you can adapt the reference code from last time, and change the struts.xml to include the internal call. >to get the SSL Certificate that is passed to Tomcat from Apache > front end. This is done with > request.getHeader("x_ssl_client_cert") > to write the eID of the citizen into the *session* attribute. > Be careful not to save it as request attribute because it must > not be traveling around with redirections that are triggered > by the PEPS following the IdPResponse. On the CitizenConsentAction, you have the HttpServletRequest and you can put that above request header into session. E.g. session.put("x_ssl_client_cert", request.getHeader("x_ssl_client_cert")); As the session object can only be acessed by CPEPS (on this case), you guarantee the security of this value. > in getAttributes > -------------------- > > to get the eID from the HTTP session that was put there with >the authenticateCitizen above You can get the eID, with the following code: session.get("x_ssl_client_cert") >As I understand, the request.setAttribute is not problematic >as it can be replaced in the new version with attributes.put, >so I can give the error code and text to show in the logs and >to the citizen. The attribute object is similiar to session object, but it as spring's request scope (you can get more info here: http://static.springsource.org/spring/docs/2.5.x/reference/beans.html#be...) >The other possibility I'm thinking about would be calling the >attribute provider immediately from authenticateCitizen and bypass >the redirections where PEPS is gathering attributes, so there >would be no need to save the userid into session. This would >obviate two uses of the HttpServletRequest above. However I'm >not sure if it's possible to make a redirection that will take >all the attributes successfully to S-PEPS' ColleagueResponse. You can redirect the CitizenConsentAction, as I explained above >If this can be done the only question would remain, how to get >the x_ssl_client_cert from Apache. See the above answer.

Thank you, Ricardo, for a detailed answer. I would prefer to wait for the next version. Marc Stern today explained in stork-wp5 mailing list how the new interfaces will look and these interfaces will solve what I want. Your idea about session can't be used to get the eID or x_ssl_client_cert down into the SpecificPEPS class, because there the variable session is not visible. Besides that I would not like touch the code in the Action classes, because then I would have to change them with every new release of common PEPS. It was meant that country specific functionality is put into SpecificPEPS class and nowhere else. You can assume this bug closed or at least suspended until the next release of PEPS.

The CitizenConsent Action is a reference code and it's for specific purposes, so we will not change it. You may change it as you wish. Your changes are SI specific, so you can modify PEPS's applicationContext.xml in order to have the session object. Just modify from <!-- Specific Bean --> <bean id="specificPeps" class="${specific.peps}" /> to: <!-- Specific Bean --> <bean id="specificPeps" class="${specific.peps}" > <property name="session" ref="session"/> </bean and implement setters and getters to the session object (on you specific class) and you be able to have the session. The communication between CPEPS and IdP/AP is just reference code, so you can change as you wish/need.

Hello, Ricardo! I'm returning to your suggestion about using session variable. Before I go studying Spring framework, can you please tell me, is your suggestion OK, regarding that SpecificPEPS is a singleton class. I'm a little sceptic that the Spring or Struts framework can set the session into SpecificPEPS and then wait that my function (authenticateCitizen or getAttributesFromAttributeProviders) returns. There can come another thread of another request in the meantime.

Hello Maks, A new PEPS version will be sent in a short time (today or tomorrow, I think) that solves a lot of problems on the specific development. We have separated the specifc Actions and Specific Class implementation to Stork-Specific Jar, in order to let the specific development becomes pluggable (so my last suggestion it's a kind of obsolete). So, in my opinion, I think that you should wait the new PEP's Release. About the session object, we have tested with JMeter and Spring can handle multiple requests, with diferent sessions.