Am trying to choose between Thinktecture Identity Server v3 and Wso2 identity server for implementing Identity and Access Management solution.
Particularly, am interested in using following features:
Single Sign-On (SSO)
Managing user identities
Connecting to central repository like Active Directory, OpenLdap, Oracle Internet Directory etc.
Active and Passive Federation
Integration with ADFS
We are a .Net based shop, so getting more inclined to Thinktecture's IS, but don't want to rule out WSO2 just because its Java (one more dependency for us)
Are there other Pros/Cons between the two?
Thanks
I'm one of the developer of WSO2 Identity server. So my answer would biased to our product :)
WSO2IS is comprehensive Identity Management platform - having support for SAML2, OpenID, XACML 3.0, OAuth 2.0, OpenID Connect, SCIM, WS-Security standards.
And it acts as an Enterprise Identity Bus (EIB) — a central backbone to connect and manage multiple identities regardless of the standards on which they are based (http://blog.facilelogin.com/2014/10/identity-federation-patterns-with-wso2.html).
Few unique features that I would like to highlight on WSO2 Identity Server are.
SSO bridging to make identity and entitlement management effortless.
Identity Federation with EIB concept.(http://blog.facilelogin.com/2014/10/wso2-identity-server-microsoft-adfs.html)
Seamless integration between internal applications and cloud apps
such as Salesforce, Google Apps, and Microsoft Office 365.
New user and group provisioning capabilities
(http://blog.facilelogin.com/2014/10/wso2-identity-server-500-provisioning.html)
Multi-option and multi-step authentication to provide flexibility in
selecting authentication options and enable robust multi-factor
authentication
(http://blog.facilelogin.com/2014/10/what-is-new-in-wso2-identity-server-500.html)
High scalability (We have a middle-east customer using WSO2 IS over
an user base of 4 million for OpenID support.)
Light-weight and Very low memory footprint. The stripped down
version of WSO2 IS can be started with 64MB Heap Size and the
standard versions runs with 96MB Heap.
Highly extensible. The architecture behind WSO2 IS is highly
extensible. You can easily plugin your authenticators, user store,
provisioning connectors etc...
Support for multi-tenancy.
Suport for multiple user stores (AD, LDAP, JDBC)
Interoperability.
Part of a proven SOA product platform provided by WSO2.
Related
We are in process of building a series of apps that will run offline or in very austere environments. We'll also be integrating with other 3rd party apps. Many of these will require logins so we're attempting to use SAML to handle login between them.
I found saml2-js:
https://github.com/Clever/saml2
And it seemed like a great starting point for both the SAML Service Provider and Identity Provider - but diving in I now see it does not implement the Identity Provider at all.
I already have a basic SAML Service Provider setup, but we need an Identity Provider that can run offline. Are there any Node or GoLang Identity Provider libraries we can use to implement this? If not, another recommendation?
Passport is the usual Node option but that's client side only.
There are a number of IDP's you can use e.g.:
Free: simpleSAMLphp / Shibboleth / identityserver4
Cloud: Auth0 / Okta / Azure AD
On-premises: ADFS
We are developing a product that consists of a set of micro services developed as Spring Rest API, those APIs will be called using Angular JS client (not confidential client to server communication) and will also interact with each other (server-to-server communication );
We are in the stage of developing an SSO solution where we also want to implement authorization based on user roles for each API, while diving more through Spring Security, I have noticed the great support for OAuth2 standard, but at the same time I saw
Implementation for a CAS server integrated with spring client;
Now my question, why would someone goes with CAS server instead of using native spring security implementation and how roles will be passed from the CAS server?
You need to further study the concept of centralized single sign-on and different components in the architecture. Spring Security is a client library mostly used by the app to contact a server of some sort. CAS, as a software system, is a server. Your client application can use any library you like to contact the "account source" or the "identity provider" server. The server on the other hand, depending on the capabilities of the client will respond and react according to the semantics of the authentication protocol used.
Roles or more accurately put, attributes and claims are passed to the client app once tokens/tickets are validated using the CAS protocol. Other protocols more or less provide the same concept.
When using a passive client (say web browser) and are using WS Federation with an STS such as ADFS, SSO is achieved to the relying parties. Is this apart of the WS Federation specification (that is, when using passive clients SSO will be achieved with WS Federation) or is this an implementation detail of ADFS (that is, ADFS sets a cookie so you only need to authenticate to ADFS once.. just beacuse the Microsoft developers thought it would improve user experience)?
It is a standard which is also supported by many other products.
https://en.wikipedia.org/wiki/WS-Federation_Passive_Requestor_Profile
http://janbernhardt.blogspot.com/2014/12/understanding-ws-federation-passive.html
WS-Federation Passive Requestor Profile is a Web Services specification - intended to work with the WS-Federation specification - which defines how identity, authentication and authorization mechanisms work across trust realms. The specification deals specifically with how applications, such as web browsers, make requests using these mechanisms. In this context, the web-browser is known as a "passive requestor." By way of contrast, WS-Federation Active Requestor Profile deals with "active requestors" such as SOAP-enabled applications. WS-Federation Passive Requestor Profile was created by IBM, BEA Systems, Microsoft, VeriSign, and RSA Security.[1]
We are doing a Cloud POC, we will have applications hosted in the cloud that can only talk LDAP. Is there any system/appliance/virtual directory in the cloud that can appear to be an LDAP server from the application side, and on the output side talk SAML/REST based over the Internet to talk to our SSO product that can authenticate users against our corporate LDAP, which is tucked inside our internal firewall?
You need to deploy an Identity provider connected to the ldap. You can adopt CAS or SAML technology.
In that wikipedia entry you can check the differents products (commercial and free software):
http://en.wikipedia.org/wiki/SAML-based_products_and_services
Most of them support Ldap as the authentication source backend.
Also Take a look on this thread:
Way to single sign on between PHP, Python, Ruby applications
The emerging SCIM (System for Cross-domain Identity Management) protocol might make more sense for the use case you're illustrating. It's intended to provide a simple REST API around an identity store so you can perform Create/Read/Update/Delete operatons. What will be available could theoritically be controlled via some policy within a SCIM server to alloy your clients to essentially interact with the backend LDAP directory.
Many products are adopting the SCIM standard now, such as ones from Ping Identity, Salesforce and UnboundID.
These are numerous technologies and buzzwords used for single sign-on with Microsoft services.
Can someone explain ADFS, WIF, WS Federation, SAML, and STS (Security token service), including where and when each is being used.
ADFS (Active Directory Federation Services) - Off-the-shelf Security Token Service (STS) produced by Microsoft and built on Windows Identity Foundation (WIF). Relies on AD for authentication. Can be used in active (SOAP web services) or passive (web sites) scenarios and supports SAML tokens, WS-Federation, WS-Trust and SAML-Protocol. It can be used as an Identity Provider (against AD) or as a Federation Provider.
http://technet.microsoft.com/en-us/library/adfs2(v=ws.10).aspx
WIF (Windows Identity Foundation) - The .NET library used to drive claims-based authentication in .NET applications and relying parties. It can also be used as a WS-Trust client and to a build custom STS.
http://msdn.microsoft.com/en-us/security/aa570351
WS-Federation - A protocol used by relying parties and an STS to negotiate a security token. An application requests a security token from an STS using WS Federation, and the STS returns (most of the time) a SAML security token back to the application using the WS Federation protocol. This is usually via HTTP (GETs and POSTs and redirects). Contrast this with WS-Trust, which is completely web service-based.
http://msdn.microsoft.com/en-us/library/bb498017.aspx
SAML Tokens (Security Assertion Markup Language) - This is simply the XML format used for security tokens, that typically capture user information (claims) and other relevant security-related data (signatures, token issuer, etc). The token is used by the application to authenticate users and drive application behavior (e.g. authorization). SAML Security Tokens are signed for integrity and optionally encrypted so only RP and STS can see its contents. In ASP.NET web sites using WIF, the token is by default encrypted and chunked into cookies, but this can be changed.
http://en.wikipedia.org/wiki/Security_Assertion_Markup_Language
STS (Security Token Service) - As described above, the STS is the broker that sits between a relying party application and the user. An STS is an issuer of security tokens. "Issuer" is often a synonym of an STS. STSs are configured in two roles: as identity providers (IdP) when they authenticate users or as federation providers (FP) when they sit in the middle of a trust chain and act as "relying parties" for other IdPs. IdPs need a way of authenticating users. Some (like ADFS) use Active Directory, others use custom databases like SQL Server Membership (not ADFS). If the user properly authenticates, the STS will issue a security token.
http://msdn.microsoft.com/en-us/library/ff650503.aspx
http://docs.oasis-open.org/ws-sx/ws-trust/v1.4/os/ws-trust-1.4-spec-os.html#_Toc212615442
Hopefully this helps. There are a lot of concepts and pieces to understand in claims-based authentication. To get a full understanding, you should check out A Guide to Claims-Based Identity and Access Control.
From a big picture viewpoint:
Assume an ASP.NET browser-based application that requires authentication and authorization.
The application can roll its own or it can outsource it.
WIF is a .NET library that allows ASP.NET to implement this outsourcing.
It talks to an STS (ADFS is an instance of an STS) which authenticates against an identity repository and provides authorization information in the form of claims. An STS provides a set of signed, trusted claims.
The protocol used between WIF and ADFS is WS-Federation.
If the STS was Java based (e.g Ping Identity or OpenAM), then WIF would use the SAML protocol for communication. ADFS also supports SAML to enable federation.
(Federation e.g. allows a user in a Java oriented company A to access the ASP.NET application in a .NET oriented company B by authenticating against A's identity repository. Company A and company B trust each other in a federation sense.)
This post is aimed at clarifying SAML Tokens, supported in ADFS 2.0, and SAML protocol, not supported until ADFS 3.0, the version of ADFS in Windows Server 2012 R2
1) The SAML protocol is not supported prior to ADFS 3.0
2) .net 4.5 based WIF applications require using the WS-Fed protocol and currently do not support SAML-Protocol
3) SAML Tokens are XML based. SAML tokens are supported in ADFS 2.0 and previous versions. ADFS 1.0. 1.1. and 2.0 only support the SAML Tokens, not protocol
4) If you are using WIF, WS-Fed (protocol) is required - so you could do the following:
SAML Protocol <---> ADFS <----> WS-FED <----> WIF (.net 4.5)
From Wiki:
• ADFS 1.0 - Windows Server 2003 R2 (additional download)
• ADFS 1.1 - Windows Server 2008 and Windows Server 2008 R2.
• ADFS 2.0 - Windows Server 2008 and Windows Server 2008 R2 (download
from Microsoft.com)
• ADFS 2.1 - Windows Server 2012.
• ADFS 3.0 - Windows Server 2012 R2.