-
Suggestion
-
Resolution: Fixed
-
None
-
None
When CWD-314 was implemented we were able to meet the current functionality for JIRA & Confluence integration by having Crowd's JIRA integration (via Seraph) use the credentials present in the URL to be used for that given request; when grabbing RSS feeds from JIRA.
To take this one step further we should now use the authenticated 'browser user' and not the credentials present in the request to authenticate the user; however we may need to keep backwards compatibility here by allowing both.
Currently the Confluence jiraissue macro makes its request on the server side to JIRA, this means that Confluence is making the request to JIRA and not the browser, so any credentials present in the browser session are not used by Confluence for the request. We have two options (from what I can see to implement this feature):
- Provide a configuration item to the jiraportlet marco to tell it to grab the Crowd authentication token from the users session (cookie) and use that (assuming that we are on the same domain).
- Re-write the plugin as an 'ajax-based' macro so the browser makes the request and not Confluence, this would then simply use the currently authenticated Confluence user for the request on JIRA.
- relates to
-
- Closed
-
- Closed
[CWD-523] The Confluence JIRA Issue macro currently uses the hard coded os_username and os_password properties for authentication, it would be nice to use the authenticated user in the browser.
Preston Tollinger
added a comment - While the PKI method sounds reasonable at the high level, I would like the individual user authentication level to apply to whatever data they are retrieving from the other system.
While I understand creating PKI for everyone else, how about a more integrated version for those of us who DO have crowd.
Preston Tollinger
added a comment - While the PKI method sounds reasonable at the high level, I would like the individual user authentication level to apply to whatever data they are retrieving from the other system.
While I understand creating PKI for everyone else, how about a more integrated version for those of us who DO have crowd. Thanks for the update.
From your description, you will implement a sort of trust relationship between CF/JIRA using PKI, right?
I think that what's missing from CROWD to do this is a model how to authorize systems that act on behalf of users.
CAS has a mechanism for this, called proxy authentication - pretty neat.
The trouble with these type of mechanisms is that they are difficult to integrate if the application in question
do not explicitly support this type of integration hook - ie integrate into the RPC bit that calls another system.
That's why we never did this with CAS.
I think adding inter-system authentication capabilities to CROWD would benefit CROWD much more, as it would
increase it's reach (currently it's 'just a Web SSO') and grow it towards an identity management solution.
On the other hand, I may just harmed my own cause by suggesting something which may be a little bit more difficult to implement than PKI 
Justin Koke
added a comment - A quick update on this issue.
As many of you are aware this problem has been outstanding for quite some time for JIRA and Confluence
A spec has been written that will add support for a trust relationship between 'applications', this is done at the application level and not at the Crowd level, we want this to work for all our customers, just not those that have Crowd.
Trust will be created via a public/private key authorisation.
I will update this issue when I know for certain that this spec has been scheduled onto the JIRA and Confluence road maps.
Justin Koke
added a comment - A quick update on this issue.
As many of you are aware this problem has been outstanding for quite some time for JIRA and Confluence
A spec has been written that will add support for a trust relationship between 'applications', this is done at the application level and not at the Crowd level, we want this to work for all our customers, just not those that have Crowd.
Trust will be created via a public/private key authorisation.
I will update this issue when I know for certain that this spec has been scheduled onto the JIRA and Confluence road maps.
Come on guys,
we have Confluence from Atlassian, JIRA from Atlassian and even an SSO System from Atlassian.
And we still have to store passwords in Confluence pages. I am underwhelmed. 
Please please fix this in 1.2.
Justin Koke
added a comment - Unfortunately, this is only available if the user has decided to use "remember me".
There is actually a third option that does not involve Crowd, and is a more general discussion we have been having here internally around building trust relationships between Atlassian products. ie This Confluence instance can talk to 'that' JIRA instance.
Justin Koke
added a comment - Unfortunately, this is only available if the user has decided to use "remember me".
There is actually a third option that does not involve Crowd, and is a more general discussion we have been having here internally around building trust relationships between Atlassian products. ie This Confluence instance can talk to 'that' JIRA instance. 
Nina Engels
added a comment - ... I think that you can fetch user's password from the session via decodeCookie Method ..., it is the opposite from the encode Method, ...so the password information is available..
Cheers,
Nina
Nina Engels
added a comment - ... I think that you can fetch user's password from the session via decodeCookie Method ..., it is the opposite from the encode Method, ...so the password information is available..
Cheers,
Nina 
Versions of JIRA and Confluence have been released that provide Trusted Application support, allowing secure communication between the applications.
This issue is therefore moot. If you have concerns or would like additional functionality, as always, please let us know.