Redirect question in confluence using custom authenticator

[Giovanni Marrufo]

I have a confluence custom authenticator working; however I'd like to know if this is possible:

The user receives an email with a link to a confluence document. A "deep link".

The user clicks that link but doesn't yet have a session.

Custom authenticator redirects the user to the authentication source, but instead of just sending an authentication request, it also includes the parameter RelayState containing the URL that the user was trying to reach.

Authentication source authenticates the user and builds a SAML response.

The user is sent back to Confluence with that SAML Response. The request now also contains the RelayState parameter holding the URL that the user was trying to reach initially.

After the custom authenticator has validated the SAML Response, instead of redirecting the user to the dashboard, it should redirect the user to the URL in the RelayState parameter.

Obviously if the RelayState parameter is not present or empty, it should just redirect to the dashboard.

Any help would be greatly appreciated.

Thanks,

GC

[Joe Clark]

You could implement a servlet filter that looks for the RelayState parameter and changes it to an "os_destination" parameter. "os_destination" is what Confluence & JIRA use to issue redirects within the app.

[Giovanni Marrufo]

How do you set up that parameter? using a request.SetAttribute("","")? Can you point to me to a piece of code?

Thanks,

GMC

[Giovanni Marrufo]

never mind i found out how

[Joe Clark]

Cool :-) It can be either a query parameter on the URL or a parameter in the request body.

[Giovanni Marrufo]

So How does it redirect out of the app, specially before the user has been authenticated?

[Joe Clark]

Sorry, I don't understand the question - the os_destination query parameter is only for redirecting within the app. Isn't the initial redirect to the remote authentication system handled by your custom code?

[Giovanni Marrufo]

Right but the issue is that it iterates multiple times into the custom authenticator, in another post you mentioned that it should go only once thru that process but it doesn't, see piece of log:

1: /display/ds/Creating+a+Page

1: /display/ds/Creating+a+Page

1: /display/ds/Creating+a+Page

6-1: /pages/viewpage.action

6-1: /pages/viewpage.action

6-1: /onelogin.jsp

6-1: /onelogin.jsp

As you can see it goes multiple times, now my question is: could it be because in the section where I deal with creating the authentication request I go to other classes (custom ones), see code:

AppSettings appSettings = new AppSettings();

appSettings.setAssertionConsumerServiceUrl("http://localhost:8090/dashboard.action");

appSettings.setIssuer("http://localhost:8090/dashboard.action");

AccountSettings accSettings = new AccountSettings();

accSettings.setIdpSsoTargetUrl("XXXXXXXXXXX");

AuthRequest authReq = new AuthRequest(appSettings, accSettings);

Any help would be greatly appreciated

GMC

[Giovanni Marrufo]

Actually is not the custom authenticator going to other classes, I took them out and the CA still iterates many times, some more pieces to the puzzle:

1. If I try to get into confluence thru the email link I get the iterations you see in the comment above

2. If I try to get into confluence using http://localhost8090/dashboard.action as my point of entry I get this:

6-1: /dashboard.action

6-1: /dashboard.action

6-1: /dashboard.action

6-1: /dashboard.action

6-1: /dashboard.action

6-1: /onelogin.jsp

6-1: /onelogin.jsp

3. If I try get into confluence using http://localhost:8090 I get this:

6-1: /

6-1: /

6-1: /homepage.action

6-1: /homepage.action

6-1: /homepage.action

6-1: /homepage.action

6-1: /homepage.action

6-1: /onelogin.jsp

6-1: /onelogin.jsp

Any ideas?

GMC

[Giovanni Marrufo]

I also have a screenshot of a Fiddler session, where shows that the process goes to multiple URIs

[Brad Baker [Atlassian]]

@Giovanni,

Not sure exactly what is happenign for you but os_destination works for me in native JIRA

https://jira.atlassian.com/?os_destination=/browse/JRA

You must get your Authenticator class and external authentication site working together in terms of shared secret (eg how would the Authenticator know that the external site has authenticated a user?)

Not also that the login gadget in JIRA does NOT redirect. Only login.jsp does. Once is a part page gadget while the other is a full HTML page in browser terms.

You can contact me directly at brad.baker@atlassian.com for further help. I will try to do my best to help you.

[Matt Ryall]

Christian – if there is no current user found in the request (i.e. getUser() returns null) and the page requires authentication to access, then the SecurityFilter will redirect to the configured login page in seraph-config.xml. This is the same in both JIRA and Confluence.

GMC – absolute URLs should work with the login.url parameter. Did you get some error message or an incorrect redirect? You need to use "${originalurl}" in the query parameters, as the code does a literal search/replace for this.

JIRA uses the same library and the same mechanism as Confluence, except its login URL is login.jsp. If you hit JIRA's login.jsp with an "os_destination" parameter, and your authenticator's login() returns true and getUser() returns a valid user, that user will be redirected by the LoginFilter to that location.

Apologies for the difficulty in getting this working. We'd really like to change to using a better HTTP security library, but the amount of effort involved has prevented us doing this so far.

[Giovanni Marrufo]

Hi Matt I hope you can throw some light in this behavior from Jira, I understand when you say that login.jsp deals with the authentication and I'm using it in the seraph.xml passing the os_destination, however when it always presents me with the login pageant doesn't go to the authentication source. I have no problem sending you code or screen shots to show you my dilemma, at the end it might be something son simple that I'm probably missing. Is there a way I can communicate with you directly? Please let me know

[Matt Ryall]

Giovanni, I think you need to follow the steps I posted on your other question.

You need to put your external IDP URL in seraph-config.xml, _not_ the JIRA login.jsp URL.

Then your IDP configuration needs to redirect back to the JIRA login.jsp with an "os_destination" parameter. It should include enough information in the request for your custom authenticator to verify the request in the login() and getUser() methods.

I've asked Brad to help you out, because he has done a lot of work with JIRA authentication. I'm also happy to help out further if necessary - matt@atlassian.com.

[Christian Pedersen]

Thank you, Matt

So, only if the custom authenticator fails to return a user, will the user be redirected to the login.url? (first call the autenticator, then redirect to login.url if the authenticator doesn't return a user - is that accurate?).

- Christian

[Giovanni Marrufo]

these are the different options I tried with the login.url:

<param-name>login.url</param-name>

1. <!--<param-value>/login.action?os_destination=${originalurl}</param-value>-->

2. <!--<param-value>/onelogin.jsp</param-value>-->

3. <!--<param-value>https://app.onelogin.com/saml/signon/38600?SAMLRequest=${os_destination}</param-value>-->

4. <param-value>/onelogin.jsp?os_destination=${originalurl}</param-value>

#1 is the original that comes with seraph, that does not work for me

#2 I use this jsp because I need to pass a long string of data to the iDP, I am able to redirect from the jsp and do the whole trip back to confluence, our problem is when we try to use a deep link from an emai

#3 I tried that also using the actual URL of the iDP and trying to pass parameters, didn't work

#4 was trying that tonight to see if I can get the originalurl to work for me, didn't either

The iDP has a setting on its end that points to http://localhost:8090/dashboard.action, when I use the SecurityFilter.ORIGINAL_URL I always get the "dashboard.action" is not taking the Referer URL, in this case the deep link of the email

[Giovanni Marrufo]

Ok, I got the Custom Authenticator working the way I wanted in Confluence, however now I have to do the same for JIRA, questions:

1. How do you redirect internally in JIRA? In Confluence you can use os_destination but you need the LoginAction class to set the OS_DESTINATION, How do you do it in JIRA? What is the class you use to replace LoginAction?

2. Related to 1, I also need to get the Original URL once comes back, I'm using this:

String originalURL1 = (String) request.getAttribute(SecurityFilter.ORIGINAL_URL);

Here the SecurityFilter is needed, Can I use the same in JIRA? if Not How is the way to get that value?

Any help woud be appreciated.

GMC

[Christian Pedersen]

Allow me to chime in here. The question pretty much boils down to how to redirect from the custom authenticator directly to our IdP site, without having to use an intermediate JSP file for just this purpose. I think if we were able to do that easily, that would solve an array of issues.

- Christian

[Matt Ryall]

This sounds like a misunderstanding about how custom authentication works in Confluence. The basic steps are:

1. Change seraph-config.xml to customise the "login.url" property to point to the external authentication site.
2. Make sure the external authentication site redirects back to Confluence after authentication, usually by customising the request parameters in the "login.url".
3. Write a custom authenticator class, which is a subclass of ConfluenceAuthenticator, that overrides the getUser(Request,Response) method to verify the credentials in the request passed by the external authentication service.
4. Drop the compiled class file in WEB-INF/classes/ and update seraph-config.xml to reference the custom authenticator.

It sounds like you've got steps #3 and #4 sorted out, but haven't taken care of #1 or #2 yet.