JIRA Service Knowledgebase Public Article W/O Anon Access to Space

[Carl E_ Allen]

Greetings all!

I have a bit of a head-scratcher and I am hoping someone has an idea.

We have a JIRA service desk (and confluence) The JIRA service desk has Public account creation turned on (through e-mail) -- and they want to use a knowledge-base through the portal.

Requirements I was given:

>  External Customers share the same Confluence as Employees

> Both Confluence and JIRA have to have a SAML SSO Addon

> The Knowledge-base cannot be "anonymous"  

> The Knowledge-base shouldn't ask customers to log in a second time.  

Internal users can search using the portal just fine... when one of those customers who created their account by e-mail cannot get those articles, obviously, because they are not authenticated.

I can get it working if the Knowledge-base is set to Anonymous, but that is one of the things we aren't supposed to do.

Next  I added JIRA user directory to confluence. (Customers get created in jira when they e-mail in, they setup their password.)

That somewhat worked, in the portal customers could read the preview of he article, but are prompted to login to get the full article if they click on it (then my SSO addon takes over and they can't login cause they're not LDAP users)

Next I turned off my SAML SSO add-on, I can view the preview of the article, I click on the article, I am prompted to login to confluence, (as the customer) I do, and when I go back to confluence it works, -- however, the customer would have to log into the portal, AND the confluence to get the articles. 

I guess in short, is there a way to get JIRA service desk to allow users to browse "AS" an authenticated user without actually making that user authenticate? 

Any ideas would be helpful.

[Carl E_ Allen]

Thanks for the reply:

Yes my Viewing is setup correctly:  "All active users and customers can access the knowledge base without a Confluence license."

However when my customers are served is this:

They get a preview when they type in, but if they click on it, are told to log into confluence... 

Since JIRA and Confluence share a user directory (but we don't have crowd) -- they are able to log in, but that's not a great user experience. 

The ONLY way I've gotten this to work as I think its intended, is to have the Confluence space that the Service desk uses as its KB set to Anon, and then it works just fine. 

[AnnWorley]

Hmmm... Thanks so much for the screen shot.

If SSO is enabled and they click that "log in to Confluence" button do they have to type credentials again to log in or do they go straight to the article? What if the remember me box is checked as in the message, does it allow seamless browsing afterward? (until the remember me cookie is gone?) I don't know how the third party SAML SSO plugins work, but with Crowd SSO the authentication is cookie-based, once you have the SSO cookie from one app, none of the other SSO-enabled apps challenge for login. Perhaps the add-on works similarly.

Please let me know which SSO add-on solution you are using. It seems like that plugin should make sure you are not challenged to log in by one app after logging into the other if SSO is in place.

[Carl E_ Allen]

This is where my problem gets complex, our user directories in confluence and JIRA are (LDAP) Active directory on Top (for the internal company) and then internal directory below that for our customers accounts to get created in.

This is why if I disable our SSO addon, then the customers can login.

SAML SSO Addon we use is from Reichert -- https://marketplace.atlassian.com/apps/1212130/saml-single-sign-on-sso-jira-saml-sso?hosting=server&tab=overview

If I turn on SSO then my customers are redirected to my Active Directory Federation Services (ADFS) login page (where they DEFINITELY can't login -- as they're not in our Active Directory).

I'm kinda getting to "we just need an Anon Space" but thank you for the back and forth, I'm enjoying this!

[AnnWorley]

It is complex and I agree it's fun to discuss possible options. It makes sense to have external customers in a different user directory but that may be what is causing the extra friction (logging into Confluence). I agree that seeing a promising kb with a link and then being prompted to log in when you click it is a less-than-optimal experience.

I am going to move your question to the Marketplace collection and tag it "Reichert" to see if we can get the vendor to join the party. They may know whether it is possible or we are spinning our wheels.

I will still be keeping an eye on the question, of course.

[AnnWorley]

You have probably seen this article:

Serving customers with a knowledge base

It sounds like the Viewing setting may what needs to be adjusted:

The Viewing setting determines who can view articles via the Help Center or a link your team shares. This is an important setting, because knowledge base pricing is based on the number of team members who have a Confluence license.

Users who have a Confluence license can create, comment on, and search all of the spaces on your Confluence site. Users who don't have a Confluence licence can't create content, but you can give them permission to view your knowledge base content for free.

If you are using SSO your Confluence users should not have to re-authenticate. Your unlicensed knowledge base viewers should also be able to view the knowledge base.

I think that browsing as if authenticated without authenticating again sounds like the functionality of letting unlicensed users browse the knowledge base, which is a feature that can be provided when the kb is set up as in the link above,