<div dir="ltr">Ah that's quite a nice option Colin :)<div><br></div><div>A more expensive but simpler way to go if you don't want to roll your own, is to pay for a service that does that for you. We looked at a few 2 years ago and one that was okay was PingIdentity</div><div><a href="https://www.pingidentity.com/en/products/pingfederate.html">https://www.pingidentity.com/en/products/pingfederate.html</a><br></div><div><br></div><div>At the time I commented to my colleagues we could set our own stuff up around ADFS in Azure more cheaply (because of a large educational discount). It does depend on your situation, user volumes and so on.</div><div><br></div><div>Regards, Peter</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr">On Fri, 19 Feb 2016 at 10:56 Colin Newell <<a href="mailto:colin.newell@gmail.com">colin.newell@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">There are applications designed to provide an authentication server<br>
that can be dropped into place.  Keycloak is the one I came across<br>
recently that allows you to provide your own OAuth authentication<br>
server.  It also conveniently has a docker container image that makes<br>
it very easy to try quickly.  Well as quickly as you can setup oauth2<br>
integration....<br>
<br>
<a href="http://keycloak.jboss.org/" rel="noreferrer" target="_blank">http://keycloak.jboss.org/</a><br>
<a href="https://registry.hub.docker.com/u/jboss/keycloak/" rel="noreferrer" target="_blank">https://registry.hub.docker.com/u/jboss/keycloak/</a><br>
<br>
Note that this still isn't all that simple, but if you wanted to<br>
support OAuth2 from multiple providers but still allow users to sign<br>
up with your own authentication provider if they don't want to use<br>
their external account a solution using a server like that might be of<br>
use.<br>
<br>
As Peter says, there is no single answer, and definitely no simple<br>
answer when it comes to OAuth2 (try to avoid the  original OAuth).<br>
<br>
<br>
Colin.<br>
<br>
On 19 February 2016 at 10:38, Peter Edwards <<a href="mailto:peter@dragonstaff.co.uk" target="_blank">peter@dragonstaff.co.uk</a>> wrote:<br>
> We looked about a year ago at how to do federated identity between a few<br>
> systems. One was C# with a custom (don't ask) version of SAML, one was<br>
> Drupal PHP and the underlying authentication provider was MS Active<br>
> Directory.<br>
> SAML and OAuth2 solve different kinds of problem and present different types<br>
> of difficulty. There are plenty of good decks on <a href="http://slideshare.net" rel="noreferrer" target="_blank">slideshare.net</a> that go into<br>
> this.<br>
> Because we were doing a client side Single Page Application which needed the<br>
> authentication then routing of service API calls from REST to a SOAP XML<br>
> backend, it turned out easiest for us to use OAuth2 and do mapping in an<br>
> integration platform on MS Azure to SAML 2.0 make the different systems work<br>
> together.<br>
> As Tom says, there is no single simple answer. It depends what you're trying<br>
> to do, what components you've already got and who your audience is<br>
> (internal, external) and what application they are using, e.g. is it a<br>
> chromebook, mobile app, corporate desktop.<br>
> Cheers, Peter<br>
><br>
> On Fri, 19 Feb 2016 at 10:26 Tom Hukins <<a href="mailto:tom@eborcom.com" target="_blank">tom@eborcom.com</a>> wrote:<br>
>><br>
>> On Fri, Feb 19, 2016 at 09:43:17AM +0000, Peter Edwards wrote:<br>
>> > I'd suggest using OAuth2 and either running your own provider or<br>
>> > hanging it off Google/MS Live/github depending who your audience is.<br>
>><br>
>> Everyone I know who has tried to support OAuth2 has found the experience<br>
>> painful.<br>
>><br>
>> This brief talk shows why people find it confusing:<br>
>> <a href="https://www.youtube.com/watch?v=xeGxGnSkSdQ" rel="noreferrer" target="_blank">https://www.youtube.com/watch?v=xeGxGnSkSdQ</a><br>
>><br>
>> I don't have a good answer to Andy's question unfortunately.  I doubt<br>
>> anyone outside the Perl community uses Bitcard, so it doesn't provide<br>
>> SSO for most people.  If you need SSO, you probably want OAuth, but if<br>
>> you don't, avoid the hassle.<br>
>><br>
>> Tom<br>
>> _______________________________________________<br>
>> MiltonKeynes-pm mailing list<br>
>> <a href="mailto:MiltonKeynes-pm@pm.org" target="_blank">MiltonKeynes-pm@pm.org</a><br>
>> <a href="http://mail.pm.org/mailman/listinfo/miltonkeynes-pm" rel="noreferrer" target="_blank">http://mail.pm.org/mailman/listinfo/miltonkeynes-pm</a><br>
><br>
><br>
> _______________________________________________<br>
> MiltonKeynes-pm mailing list<br>
> <a href="mailto:MiltonKeynes-pm@pm.org" target="_blank">MiltonKeynes-pm@pm.org</a><br>
> <a href="http://mail.pm.org/mailman/listinfo/miltonkeynes-pm" rel="noreferrer" target="_blank">http://mail.pm.org/mailman/listinfo/miltonkeynes-pm</a><br>
><br>
</blockquote></div>