[tsobis]

Ok, after a lot of testing and debugging, I found out that the combination of url rewrite from ocpsoft with picketlin is working, however, if I add the SecurityConfigurationBuilder from the picketlink exceptions arise all over the code.

I hope this helped and wandering if it is possible to combine the ocpsoft rewrite with picketlink correctly.

Greatly Appreciated

[pcraveiro]

Got your example working.

The main issue here is that the SecurityFilter is applied before the FacesServlet. The FORM authentication supported by the Http Security API is based on HTTP FORM Authentication. Which means you need to submit your form to a specific URI (eg.: /j_security_check) along with the j_username and j_password parameters.

Considering that, the authentication is being performed after the SecurityFilter. Thus, you will never be redirected to the original URL given that this feature is provided by this filter (and the form authentication scheme).

Can you change your login form to something like that [1] ?

Btw, I'm thinking on how to support JSF-based login as well ...

[1] jboss-picketlink-quickstarts/login.xhtml at master · jboss-developer/jboss-picketlink-quickstarts · GitHub

Cheers.

[pcraveiro]

I've pushed some changes to my fork of example [1].

Basically, my changes are:

1) Force RewriteFilter to happens first then PL SecurityFilter. Check web.xml.

2) Added a rewrite rule to .addRule().when(Path.matches("/login.jsf").and(RequestParameter.exists("j_username").and(RequestParameter.exists("j_password")))).perform(Forward.to("/j_security_check"))

3) Changed login page to send j_username and j_password.

4) Clean up to the authentication controller. Did that because you can't use JSF resources from there because FacesServlet is invoked only later on. And that causes injection errors. It is now simple enough to have only the logic to authenticate the user.

5) Removed unnecessary dependency on jboss-deployment-structure.xml

After those changes, I can see PL trying to redirect the user to the original URL from the firefox web developer (network).

Please, let me know what you think ...

[1] Fixing rewrite integration. · 477d3e1 · pedroigor/example · GitHub

Regards.

[pcraveiro]

I've also fixed some issues in your example. And added authentication based on PicketLink IDM. For that I`ve just removed your AuthenticatorController and added a SecurityInitializer to create your user during startup.

[pcraveiro]

I`ve improved JSF-based FORM authentication. Please, take a look at:

https://issues.jboss.org/browse/PLINK-656

https://issues.jboss.org/browse/PLINK-657

In this case, you are not forced to use rewrite at all. But just change the authentication URI as demonstrated in the quickstart.

[tsobis]

Hello,

Your solution is very simple to understand, however, firstly I thing that I need the exclusion of <module name="org.picketlink" /> since I am using the latest version of pickelink on the project only, and the testing server is jboss eap 6.2 (which has picketlink 2.1.9.Final) according to https://access.redhat.com/articles/112673 , secondly I use the AuthenticationController for accessing data from a database. Only for the example I have removed any database related code (to be easier to read and build) the project.

The PLINK-657 is exactly what I am looking for. Your help is greatly appreciated. I will test it tomorrow and get back to you, although I do not think that I will have any problems anymore.

Regards.

[pcraveiro]

I see.

I think that will make you move forward. In a nutshell you have two options here:

1. Use rewrite to change /login.jsf to /j_security_check. As I previously said.
2. Use latest snapshot (I've deployed it in JBoss Nexus) and do exactly what I did to that quickstart

I did #2 as an improvement and to not force people to use rewrite ...

However, you still need to keep in mind that you are not able to inject JSF related resources (eg.: FacesContext, etc) from your controller. But only the logic to properly validate credentials and authenticate your users. As I said, FacesServlet is only processed after the SecurityFilter. Also, make sure you are not using ajax when submiting the form. Otherwise you will not be redirected to the next page right after the authentication.

If the latter is an issue for you, I can try to come up with a solution to allow you use ajax on JSF-based forms.

Regards.

[tsobis]

The code works with the corrections as expected, and I do not know if this is silly but I will ask. Since the identity is statefull could you not store the requested url there from the filter (or some other session variable)? That will allow the usage of the original url by any custom authenticator that can inject the identity or some similar value, independently from the view technology.

Again, your help was greatly appreciated.