Saml 2.0 for authentication

November Happy Hour will be moved to Thursday December 5th.

AI OnAI Off

Home / Forums / Developers (Main Products) Forum / Developer to developer /

Saml 2.0 for authentication

Vote:

Hi.

We are planning to build a plattform for a customer, which has as a requierment that we use one of their systems for SSO. This system uses SAML sign-in protocol (and thus SAML 2.0 token). We havn't gotten access to this system yet, but is there any issues with this? In a previous system we used ws-federation with an azure ad, but we havn't tried using the SAML protocol. Googling this gives very little information and thus I thought to check if you have and info or example? Below is part of the code used for wsfederation.

// Enable cookie authentication, used to store the claims between requests
app.SetDefaultSignInAsAuthenticationType(WsFederationAuthenticationDefaults.AuthenticationType);
app.UseCookieAuthentication(new CookieAuthenticationOptions
{
AuthenticationType = WsFederationAuthenticationDefaults.AuthenticationType
});

// Enable federated authentication
app.UseWsFederationAuthentication(new WsFederationAuthenticationOptions()
{

Regards

Martin Andersson

Developer

Ottoboni

#122954

Jun 18, 2015 15:08

Dan Matthews

Vote:

You certainly can use SAML 2.0. The only thing to bear in mind is that you may still want to write a cookie - as you are doing. The examples I have aren't using quite the same code, but we've done SAML in several cases... personally speaking, I found this component easier than the WsFederation stuff (although I have got both working):

http://www.componentspace.com/Products/SAMLv20.aspx

I'm not endorsing it, but just saying that there are easy ways to get where you want to go!

#123667

Jul 14, 2015 12:23

Vote:

There is also this: <a href="https://github.com/KentorIT/authservices">https://github.com/KentorIT/authservices</a> I only looked into it briefly but it looks alright and can't see why it shouldn't work inside an Epi app. An alternative is to use another IDP infront of your application that understands SAML and then have that by WS-Fed connection to Epi.

#146671

Mar 21, 2016 12:13

Daniel Ovaska

Vote:

Probably best shot is like the above answers with Dan, use a separate component that helps you authenticate vs SAML idp.
Azure ACS will hopefullly have support for this in the future but not yet. Using a separate intermediary IDP feels like one too many so I would go with Dans suggestion above too. It's possible to write that code yourself but SSO and SAML gets tricky pretty fast and not very easy to debug so a tested third party component will save some money and curses. If it's likely in the future to add more IDPs then it gets more interesting to have an intermediary IDP that handles that part.

We have used http://www.e-identitet.se/ for some similar solutions before.

Don't forget single sign out :)

#146674

Mar 21, 2016 13:04

Dan Matthews

Vote:

It's probably worth saying that since I wrote my original reply, Episerver has improved their support and documentation for WS-Federation. If you are going directly to a SAML 2 IDP then maybe you still want to go with the direct approach I originally suggested, but if you can go via WS-Federation it's very clean and it does abstract the implementation... allowing integration to multiple IDP's, for example. You can read more about Episerver's WS-Federation integration here:

http://world.episerver.com/documentation/Items/Developers-Guide/Episerver-CMS/9/Security/federated-security/

I also gave a talk on this at Episerver Ascend at the end of last year, and the lab is available below. As far as I'm aware the Azure ACS server I set up is still active :)

https://t.co/LOI6X7PURC (PDF)

https://t.co/TGpGVJfVSY (ZIP)

There's no right or wrong with this, the clean approach will be the one that suits your needs best!

#146675

Mar 21, 2016 13:18

Vote:

To update the issue. The idp demanded Saml at first, and we looked at KentorIt but ended up using another service.

One problem the idp hoster stated is that saml logout requests are NOT to be trusted. Only way to be sure is to have the logout functionality redirect to local idp site and have the manually logout there.

Also at Dan, as I wrote we have done ws-federation authentication before and have not had any problems.

But to make it more intresting we have switched to OpenId AND made the actual login form hosted in our enviroment with support for multiple idp providers dependent on which site you are currently at.

Was quite tricky to get to work.

#146682

Mar 21, 2016 14:25

Daniel Ovaska

Vote:

Single Sign On is not Simple Sign On...looks easy to set up. Rarely is...

#146694

Mar 21, 2016 15:25

Vote:

I found this thread while investigating and this whole area is such a jungle.

About ACS I found this where ACS features will move into Azure AD: https://blogs.technet.microsoft.com/ad/2015/02/12/the-future-of-azure-acs-is-azure-active-directory/
Trying to follow that one up didn't lead me anywhere and when trying ACS the web UI for it seem a bit outdated so I guess it hasn't come along yet.

Also as everywhere XML is "sunset"... JWT (Json Web Token) should be more future proof than SAML.

For now Auth0 gives us all the coverage needed including role handling. Very little code and just one auth connection in the Epi site makes me happy.

EDIT: Then again reading on JWT and SAML are not fully comparable... Bah.

#146697

Edited, Mar 21, 2016 15:31

This topic was created over six months ago and has been resolved. If you have a similar question, please create a new topic and refer to this one.