<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: OpenSSO Single Sign-on Plugin for WordPress</title>
	<atom:link href="http://blog.superpat.com/2009/07/27/opensso-single-sign-on-plugin-for-wordpress/feed/" rel="self" type="application/rss+xml" />
	<link>http://blog.superpat.com/2009/07/27/opensso-single-sign-on-plugin-for-wordpress/</link>
	<description>Pat Patterson on the Cloud, Identity and Single Malt Scotch</description>
	<lastBuildDate>Thu, 23 May 2013 17:53:50 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.5.1</generator>
	<item>
		<title>By: OpenSSO Single Sign-on Extension for MediaWiki &#171; Superpatterns</title>
		<link>http://blog.superpat.com/2009/07/27/opensso-single-sign-on-plugin-for-wordpress/comment-page-1/#comment-1750</link>
		<dc:creator>OpenSSO Single Sign-on Extension for MediaWiki &#171; Superpatterns</dc:creator>
		<pubDate>Tue, 23 Feb 2010 05:03:39 +0000</pubDate>
		<guid isPermaLink="false">http://blog.superpat.com/2009/07/27/opensso-single-sign-on-plugin-for-wordpress/#comment-1750</guid>
		<description><![CDATA[[...] targeting PHP CMS applications (see my previous entries covering the extensions for Drupal, WordPress and Joomla), I decided to look at MediaWiki, the PHP application powering Wikipedia and many other [...]]]></description>
		<content:encoded><![CDATA[<p>[...] targeting PHP CMS applications (see my previous entries covering the extensions for Drupal, WordPress and Joomla), I decided to look at MediaWiki, the PHP application powering Wikipedia and many other [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Ramoonus</title>
		<link>http://blog.superpat.com/2009/07/27/opensso-single-sign-on-plugin-for-wordpress/comment-page-1/#comment-25</link>
		<dc:creator>Ramoonus</dc:creator>
		<pubDate>Sun, 02 Aug 2009 09:04:32 +0000</pubDate>
		<guid isPermaLink="false">http://blog.superpat.com/2009/07/27/opensso-single-sign-on-plugin-for-wordpress/#comment-25</guid>
		<description><![CDATA[&lt;p&gt;The best way to get this plugin to the masses is to upload it to Wordpress` plugin directory&lt;br/&gt;
then it also supports easier updating for the users&lt;/p&gt;
]]></description>
		<content:encoded><![CDATA[<p>The best way to get this plugin to the masses is to upload it to WordPress` plugin directory<br />
then it also supports easier updating for the users</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Anonymous</title>
		<link>http://blog.superpat.com/2009/07/27/opensso-single-sign-on-plugin-for-wordpress/comment-page-1/#comment-24</link>
		<dc:creator>Anonymous</dc:creator>
		<pubDate>Wed, 29 Jul 2009 01:21:13 +0000</pubDate>
		<guid isPermaLink="false">http://blog.superpat.com/2009/07/27/opensso-single-sign-on-plugin-for-wordpress/#comment-24</guid>
		<description><![CDATA[&lt;p&gt;Pat, a redirect within two seconds will not indicate a loop - at least not for us. We have the &#039;problem&#039; where our backend application is behind sjsws acting as a URL policy enforcement point.  In CDSSO mode the first access to that application is the POST of LARES, this post is proxied back to the app, but without the session cookie in the request as that cookie is set on response to the LARES.&lt;br/&gt;
Because the backend app requires the session cookie (it uses j2ee agent - though it could be because it uses SDK) it redirects back to login which imediately redirects back as the user is authenticated, this time the session cookie comes through.&lt;br/&gt;
I thought there was already an option to stop redirects after a number of redirects - will try find that setting...&lt;/p&gt;
]]></description>
		<content:encoded><![CDATA[<p>Pat, a redirect within two seconds will not indicate a loop &#8211; at least not for us. We have the &#8216;problem&#8217; where our backend application is behind sjsws acting as a URL policy enforcement point.  In CDSSO mode the first access to that application is the POST of LARES, this post is proxied back to the app, but without the session cookie in the request as that cookie is set on response to the LARES.<br />
Because the backend app requires the session cookie (it uses j2ee agent &#8211; though it could be because it uses SDK) it redirects back to login which imediately redirects back as the user is authenticated, this time the session cookie comes through.<br />
I thought there was already an option to stop redirects after a number of redirects &#8211; will try find that setting&#8230;</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: horto</title>
		<link>http://blog.superpat.com/2009/07/27/opensso-single-sign-on-plugin-for-wordpress/comment-page-1/#comment-23</link>
		<dc:creator>horto</dc:creator>
		<pubDate>Tue, 28 Jul 2009 18:43:17 +0000</pubDate>
		<guid isPermaLink="false">http://blog.superpat.com/2009/07/27/opensso-single-sign-on-plugin-for-wordpress/#comment-23</guid>
		<description><![CDATA[&lt;p&gt;bravo, pat!&lt;/p&gt;
]]></description>
		<content:encoded><![CDATA[<p>bravo, pat!</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Pat Patterson</title>
		<link>http://blog.superpat.com/2009/07/27/opensso-single-sign-on-plugin-for-wordpress/comment-page-1/#comment-22</link>
		<dc:creator>Pat Patterson</dc:creator>
		<pubDate>Tue, 28 Jul 2009 16:43:45 +0000</pubDate>
		<guid isPermaLink="false">http://blog.superpat.com/2009/07/27/opensso-single-sign-on-plugin-for-wordpress/#comment-22</guid>
		<description><![CDATA[&lt;p&gt;Damien - yes - I think that is the correct behavior. If we have a username from OpenSSO, but there is no corresponding user in the other system we should show an error page and stop the redirect madness :-)&lt;/p&gt;
&lt;p&gt;I&#039;m also thinking about how to detect and stop redirect loops in general - for instance, if you misconfigure the OpenSSO cookie name or the DNS domains don&#039;t match. I&#039;m thinking about a cookie holding the time we did the redirect. If we try to do another redirect to the OpenSSO login page within (say) 2 seconds of the last one, we&#039;re likely in a redirect loop. I&#039;ll try this out in the Drupal/WordPress providers and see how it works.&lt;/p&gt;
&lt;p&gt;Dennis - the PHP client SDK was a contribution from the community. IIRC, we did the identity services soon after, and no one has really used (or even asked about) the PHP SDK since - not even its author. No users + no mail traffic + no bug reports =&gt; no development...&lt;/p&gt;
]]></description>
		<content:encoded><![CDATA[<p>Damien &#8211; yes &#8211; I think that is the correct behavior. If we have a username from OpenSSO, but there is no corresponding user in the other system we should show an error page and stop the redirect madness <img src='http://blog.superpat.com/wp-includes/images/smilies/icon_smile.gif' alt=':-)' class='wp-smiley' /> </p>
<p>I&#8217;m also thinking about how to detect and stop redirect loops in general &#8211; for instance, if you misconfigure the OpenSSO cookie name or the DNS domains don&#8217;t match. I&#8217;m thinking about a cookie holding the time we did the redirect. If we try to do another redirect to the OpenSSO login page within (say) 2 seconds of the last one, we&#8217;re likely in a redirect loop. I&#8217;ll try this out in the Drupal/WordPress providers and see how it works.</p>
<p>Dennis &#8211; the PHP client SDK was a contribution from the community. IIRC, we did the identity services soon after, and no one has really used (or even asked about) the PHP SDK since &#8211; not even its author. No users + no mail traffic + no bug reports =&gt; no development&#8230;</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Dennis</title>
		<link>http://blog.superpat.com/2009/07/27/opensso-single-sign-on-plugin-for-wordpress/comment-page-1/#comment-21</link>
		<dc:creator>Dennis</dc:creator>
		<pubDate>Tue, 28 Jul 2009 08:13:11 +0000</pubDate>
		<guid isPermaLink="false">http://blog.superpat.com/2009/07/27/opensso-single-sign-on-plugin-for-wordpress/#comment-21</guid>
		<description><![CDATA[&lt;p&gt;Hey, is the PHP Client still under active development? Since more than 2 years nothing happened there. You should think about providing real support for that piece of code.&lt;br/&gt;
Thanks&lt;/p&gt;
]]></description>
		<content:encoded><![CDATA[<p>Hey, is the PHP Client still under active development? Since more than 2 years nothing happened there. You should think about providing real support for that piece of code.<br />
Thanks</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Damien</title>
		<link>http://blog.superpat.com/2009/07/27/opensso-single-sign-on-plugin-for-wordpress/comment-page-1/#comment-20</link>
		<dc:creator>Damien</dc:creator>
		<pubDate>Tue, 28 Jul 2009 01:45:43 +0000</pubDate>
		<guid isPermaLink="false">http://blog.superpat.com/2009/07/27/opensso-single-sign-on-plugin-for-wordpress/#comment-20</guid>
		<description><![CDATA[&lt;p&gt;Hi Pat.  Regarding the redirection loop for OpenSSO/wordpress - the same condition exists for the Jira/Confluence plugin (seraph). I suppose the correct behaviour would be to display an error page (customisable)?&lt;/p&gt;
]]></description>
		<content:encoded><![CDATA[<p>Hi Pat.  Regarding the redirection loop for OpenSSO/wordpress &#8211; the same condition exists for the Jira/Confluence plugin (seraph). I suppose the correct behaviour would be to display an error page (customisable)?</p>
]]></content:encoded>
	</item>
</channel>
</rss>
