search

Eduix / crowd-shibboleth-module

Shibboleth authentication module and accompanying plugin for Atlassian Crowd
12 stars 11 forks source link

Error creating new user #6

Closed breagan1983 closed 7 years ago

breagan1983 commented 7 years ago

This issue could be entirely because I'm trying to make this plugin work with Atlassian Crowd 2.12.0 (Build: #751):

I seem to have this most of the way working. I setup a "Login with Shibboleth" link in my instance of Confluence, and I can trace it going through the auth steps with our campus IdP, but then it just redirects to the login page.

In atlassian-crowd.log it states:

2017-07-12 14:43:22,922 http-bio-8095-exec-22 ERROR [nordu.crowd.shibboleth.ShibbolethSSOFilter] Error creating new user com.atlassian.crowd.exception.UserAlreadyExistsException: User already exists in directory [851969] with name

Couple other notes - I do see the user generated in Crowd, so it's at least getting that far. I also verified that the users are added to a group that setup for Confluence login.

Just thought I'd toss this out there in case anybody else was using this plugin with the current versions of the atlassian suite, and possibly ran into this issue.

Many thanks to anyone that can help.

erkkiaalto commented 7 years ago

I am pretty sure I have met this problem, but it was several years ago. Check first that the Crowd application has rights to use the Shibboleth directory in Crowd.

breagan1983 commented 7 years ago

@erkkiaalto - thanks for the tip! Really appreciate it! Adding the directory to the crowd application seemed to stop that error.

Although it appears I've now moved on to the next issue:

Tracing the network requests, it seems to successfully go:

  1. Confluence Login Link -> /crowd/plugins/ssocookie?redirectTo=...., which returns a 302 to the IdP...
  2. IdP authenticates me, and moves me to a SAML2/Redirect/SSO;jessionid=xxxxID1xxx?execution=e1s2 page, which 302s to....
  3. crowdBaseURL/Shibboleth.sso/SAM2/POST, which returns a 302 to...
  4. ssocookie?redirectTo=xxxxx, which returns a 301 to...
  5. ssocookie;jsessionid=xxxxID2xxxx?redirectTo....., which returns a 404 and a Tomcat error of the requested resource is not available.

It seems like the jsessionid is changing between the initial login request and the post auth redirects. Since this is a separate issue I'll close this one out and start a new one.