Go Premium for a chance to win a PS4. Enter to Win

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 1284
  • Last Modified:

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
0
designavenue
Asked:
designavenue
1 Solution
 
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
 
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
New Tabletop Appliances Blow Competitors Away!

WatchGuard’s new T15, T35 and T55 tabletop UTMs provide the highest-performing security inspection in their class, allowing users at small offices, home offices and distributed enterprises to experience blazing-fast Internet speeds without sacrificing enterprise-grade security.

 
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
 
btanExec 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

Featured Post

 The Evil-ution of Network Security Threats

What are the hacks that forever changed the security industry? To answer that question, we created an exciting new eBook that takes you on a trip through hacking history. It explores the top hacks from the 80s to 2010s, why they mattered, and how the security industry responded.

Tackle projects and never again get stuck behind a technical roadblock.
Join Now