<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">I responded to a RFC (due in Q1 2017) where I have included the implementation of a SAML proxy for 400k users. I have looked at three options, and my findings are:</div><div class=""><br class=""></div><div class="">1. simpleSAMLphp: While it is a versatile and well-supported product, I am not so fond of with its structure and modularization. Configuration and customization may conflict with future changes in the project. This is not a problem if you fork the project for yourself.</div><div class=""><br class=""></div><div class="">2. ITS-Dirg/IdProxy: (Python based) I implemented this in a project 2 years ago, and it is a comprehensive SAML and OIDC proxy solution. However, there have been fluctuations in the dev team and you should need to have your own support resources for it. The code base is neither huge nor too complex, but mailing list support is sparse.</div><div class=""><br class=""></div><div class="">3. Shib IDP + SP with some glue code. My experience with Shibboleth SP + IDP is that it is very reliable, has responsive support, tons of documentation, and outstanding logging capabilities. </div><div class=""><br class=""></div><div class="">Against my personal preference for the Python solution (where I contributed to the code), I decided for Shibboleth, because I think that it will perform best wrt security and reliability. If that project gets a go, and people are interested in it, I am happy to contribute it to the shibboleth project. The time table of the tender wants to have a pilot solution by Q2 2017.</div><div class=""><br class=""></div><div class="">- Rainer</div><br class=""><div><blockquote type="cite" class=""><div class="">Am 02.12.2016 um 01:54 schrieb Aaron Howell <<a href="mailto:aaron.howell@deakin.edu.au" class="">aaron.howell@deakin.edu.au</a>>:</div><br class="Apple-interchange-newline"><div class="">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" class="">
<div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">
<div dir="auto" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">
<div class="">I would like to comment on the capable and robust parts of your question.</div>
<div class=""><br class="">
</div>
<div class="">Shibboleth has been a great for us - it is so robust that it made me stop blaming Java for issues. I really used to believe Java had to be a bad language that caused problems for whatever it was running - but Shibboleth proved that wrong for me
- Shibboleth has been absolutely rock solid for the 6 years we have had it running - and a many fold increase in usage has not really reflected in increased memory or CPU traffic. I think it is an absolute credit to the Shibboleth developers that I now have
to correct people when they are complaining about Java.</div>
<div class=""><br class="">
</div>
<div class="">If paying makes your company feel better about the choice - this is also technically possible: <a href="https://shibboleth.net/consortium/support.html" class="">https://shibboleth.net/consortium/support.html</a></div>
<div class=""><br class="">
</div>
<div class="">Cheers,</div>
<div class="">Aaron</div>
<div class=""><br class="">
</div>
<div class=""><br class="">
<div class=""><br class="">
<div class="">
<blockquote type="cite" class="">
<div class="">On 1 Dec. 2016, at 11:02 am, Charlton Rose <<a href="mailto:charltonrose@workfront.com" class="">charltonrose@workfront.com</a>> wrote:</div>
<br class="Apple-interchange-newline">
<div class="">
<div dir="ltr" class="">My company has several multi-tenant SaaS products and is looking for a good, customer-facing SSO solution. At present, we're expending a lot of energy examining IDaaS providers (OneLogin, Ping, etc.) – some of them quite costly – and
I've been trying to generate some interest in Shibboleth. However, I'm dealing with some "perception" problems that I'd like some help getting through. The primary perception problem is that because it's free to use, it's not going to be as capable, robust,
flexible, or as easy to use as something we can pay for.<br class="">
<br class="">
Yes, I know, it's a typical problem one runs into when trying to sell open source to a non-technical decision maker. I'm not asking for those kinds of general arguments, but rather, arguments about IDP/SSO implementation.<br class="">
<br class="">
I assume a few users on this list had the option to <i class="">not</i> choose Shibboleth, did so anyway, and are now glad they did. Can anyone offer some tips on how to present Shibboleth as a more attractive option, or explain to me why they're glad they
chose Shibboleth over some of the well-known IDaaS providers? Contrary testimonials are also welcome, I suppose.<br class="">
</div>
-- <br class="">
To unsubscribe from this list send an email to <a href="mailto:users-unsubscribe@shibboleth.net" class="">
users-unsubscribe@shibboleth.net</a></div>
</blockquote>
</div>
<br class="">
</div>
</div>
</div>
<span style="font-size: 9.0pt; font-family: 'Calibri'; " class=""><em class=""><strong class=""><br class="">
Important Notice:</strong> The contents of this email are intended solely for the named addressee and are confidential; any unauthorised use, reproduction or storage of the contents is expressly prohibited. If you have received this email in error, please delete
it and any attachments immediately and advise the sender by return email or telephone.<br class="">
<br class="">
Deakin University does not warrant that this email and any attachments are error or virus free.</em></span>
</div>
-- <br class="">To unsubscribe from this list send an email to <a href="mailto:users-unsubscribe@shibboleth.net" class="">users-unsubscribe@shibboleth.net</a></div></blockquote></div><br class=""></body></html>