Pass-thru SSO security token/SAML

I would like to produce an SSO solution that passes through a token (of sorts) securely to the end target.

The scenario is this:

Jim logs into his computer on a Windows network. He accesses his intranet which utilises his Active Directory (Windows) login (no need to retype user/pwd). He will then click on a link on his intranet, which takes him to an external website (portal). His credentials are passed along to that external website, facilitating SSO.

Once on the external website, he chooses from a menu of service providers. He selects one, clicks a link, and his security token is passed along to the service provider of choice, facilitating SSO again.

Ideally, the service provider will submit usage infromation back to the portal for tracking and billing purposes. (this can be facilitated via an API - so not really part of my question but provided for context.

I am happy to use something like ADFS and create a federated connection between Jims' network and the portal, and between the portal and the service provider - but would prefer not to have Jim's network require federation to the service provider (third party).

Any advice would be appreciated. We looked at Shibboleth, but this creates a bit of risk having to be dependent upon an Apache-based system, when the majority of our target market are Microsoft network based.

Cheers,
Brett
designavenueAsked:
Who is Participating?

[Webinar] Streamline your web hosting managementRegister Today

x
 
btanConnect With a Mentor Exec ConsultantCommented:
The service provider need to see from their trusted identity provider that you as customer provide the SAML token expected. So if it is internal adfs not exposed service provider will not be savvy with it that is why there is typically proxy and agent to handle that in web server front as described in prev posting. Adfs may federated with those the service provider trusted identity provider in the open. I may not be as savvy in such integration hence those saml service provider can advice further.

But as a whole, during claim transformation, ADFS identity providers transform their internal organizational claims to outgoing claims in a format that's available and visible to resource providers. Resource providers in turn transform the incoming claims they get from identity providers into a format that can be consumed by their proper applications.
0
 
Rich RumbleSecurity SamuraiCommented:
Actually windows does this by default!! It's actually a security nightmare. If the external site has a trust to your domain, then what you're describing will work. The caveat is you have to use IE. Firefox doesn't tap into the SSO of the OS, where IE gives away the information freely, well it used to. Things have tightened up some over the year, but adding the external site to the trusted sites list will enable this.
-rich
0
 
btanExec ConsultantCommented:
Definitely SAML and OpenID token is the way to go for interoperability and service party (SP) / identity provider (IDP) support scheme. The link has a summary.

http://en.wikipedia.org/wiki/SAML-based_products_and_services

I was thinking "PingFederate" and "Symplified" that can also have MS support.

https://www.pingidentity.com/products/pingfederate/strong-auth-secured-single-sign-on-with-phonefactor.cfm
http://www.symplified.com/features/directory-integration/

Ideally having an application delivery controller (ADC) at the perimeter should have to make the federated and SSO transparent using the token. That would be a scalable asset compared to service based and adding of agent in servers or services. UNder Citrix and F5 networks has such support

http://support.citrixonline.com/en_US/sharefile/all_files/SF090006
http://www.f5.com/products/big-ip/big-ip-access-policy-manager/specs/
0
Will You Be GDPR Compliant by 5/28/2018?

GDPR? That's a regulation for the European Union. But, if you collect data from customers or employees within the EU, then you need to know about GDPR and make sure your organization is compliant by May 2018. Check out our preparation checklist to make sure you're on track today!

 
Giovanni HewardCommented:
Here's a visual diagram of the SAML 2.0 Web Browser SSO (POST) process.

SAML 2.0 Web Browser SSO (POST)
Ref: http://en.wikipedia.org/wiki/SAML_2.0

Since 2009, Active Directory Federation Services (AD FS) 2.0 is interoperable with SAML 2.0 implementations.

See AD FS 2.0 Content Map
0
 
btanExec ConsultantCommented:
Likewise to use AD and login seamlessly to other service providers rely on the federated and trust of the identity.  Centrify talks about this with adfs and direct control agent
http://www.centrify.com/events/web_java_applications_webinar.asp

http://www.centrify.com/blogs/tomkemp/web_sso_using_adfs.asp
0
 
btanExec ConsultantCommented:
Also ADFS is built around industry standards such as the Security Account Markup Language (SAML), Web Services Federation Language (WS-Fed), and Microsoft technologies such as the Microsoft Web Browser Federated Sign-On (MS-MWBF).

If I understand correctly, ADFS can interoperate with many other STSs that are WS-Fed compatible, such as Oracle SSO, Novell Access, Ping Identity Corporation SourceID, Internet2 Shibboleth, and IBM Tivoli Manager. This means organizations or service providers can use different STS infrastructures and still create federations and enable secure access between organizations.

The Federation Service Proxy (FSP) component in ADFS acts as a user front end for the Federation Service. The FSP can be installed separately by using the Add or Remove Programs Control Panel applet's Windows Components wizard but is also automatically installed when you install the Federation Service. The FSP acts as a proxy between browsers and the Federation Service, giving the dumb browser clients something to talk to. The FSP has the same software installation requirements as the Federation Service.

The Federation Service is a security authority that shouldn't be directly exposed to your extranet or the Internet. If your federated users or partners connect to your resources from your extranet or the Internet, you should install an additional FSP in your organization's demilitarized zone (DMZ).

This link has good writing on adfs and req
http://m.windowsitpro.com/security/how-adfs-does-identity-federation
0
 
designavenueAuthor Commented:
Sorry a bit confused - do I need to federate between the customer and the end service provider AS WELL as federating from the customer to the portal?

I was hoping that I could have a trust relationship with the service provider that I could pass a SAML token to, which we build from the customer federation. Pass this token in the request header that can then redirect the customer user to the service provider and have them logged in automatically.
0
All Courses

From novice to tech pro — start learning today.