Active Directory Federation Service and IdentityServer3 are both STSes that allows Single sign-on to software systems.
I read that IdentityServer3 can use smaller (than SAML 2.0 in AD FS) JWT tokens and can be highly customizable like using different user repository.
But if I have all users in Active Directory and I can accept this bigger tokens and provide resources using AD groups will I have any benefits using IdentityServer?
In my system architecture I want to have WebAPIs connected using ESB. I will have different types of apps like mobile, Angular, desktop. I would like to use solution that will be more reliable than flexible.
Web API normally implies OAuth. ADFS 3.0 has limited support for this. ADFS 4.0 has the full stack.
ADFS 4.0 wrt. web API is functionally the same as idsrv.
Also ADFS in some cases does support JWT.
Related
I know Azure AD would probably be pretty good for crediting a enterprise-class application, i.e. something used inside a corp. However what about if I am creating a public facing internet application. I need typical identity components, sign-in, sign-out, etc. Let's just say 10,000 users. Would azure AD be good for this?
I think azure ad b2c will meet the demand.It provides business-to-customer identity as a service. Your customers use their preferred social, enterprise, or local account identities to get single sign-on access to your applications and APIs.You can customize the entire user experience with your brand.Azure AD B2C uses standards-based authentication protocols including OpenID Connect, OAuth 2.0, and SAML. It integrates with most modern applications and commercial off-the-shelf software etc.You can refer to this.
I have spent days researching into both technologies but I am still confused.
Thanks
Saml 2.0 is an older standard, invented before single page applications, REST APIs and mobile phone apps. It focuses on web application single sign on and single sign out.
OpenID Connect does web apps too, but adds support for SPAs and mobile apps and handles API security. So in many ways OIDC is the more capable of them.
There are however some things that SAML2 can do that is not in OIDC:
Federations, where one central entity presents an aggregated metadata file containing information about many Identity Providers and applications (Service Providers). InCommon in the US is one. The new European eID system eIDAS is a SAML2 federation too.
Idp initiated sign on - where the Idp is a kind of application portal. Note that this opens to session pinning attacks and is sometimes not appropriate to allow.
Application (Service Provider / Relying Party) metadata that allows the Idp to be configured by importing metadata describing the application.
Note that API security is offered in the SAML2 specs, through the ECP profile but hardly anyone uses it and there are very few implementations.
I am a beginner with ADFS and do not know where to begin. I have an AngularJS 1.4.9 application which makes Ajax calls to an ASP.NET Web API 2.2 service.
Both applications are hosted within IIS under the same site and both use Windows Authentication on my company’s intranet. I’d like to modify them to use ADFS so that these applications can be accessed from the internet without a VPN.
You are better off looking into using the web application proxy (WAP)functionality for now. WAP allows publishing internal resources and making them internet accessible.
Once you get AD FS and WAP deployed, see step 3 in https://technet.microsoft.com/en-us/library/dn280943.aspx#BKMK_3
You can then look to slowly updating your applications to use federated authentication with AD FS.
I am looking at a scenario wherein we would like to provision (i.e. create) users programmatically into AD from our app. I was wondering if AD offers any kind of SOAP based APIs that can be used for this purpose.
Anyone have experience / information regarding such a scenario?
ADFS doesn't have any users. Authentication (and "users") are always in Active Directory. There are many APIs to interact with AD. (e.g. Directory Services)
I'm not aware of a SOAP based API, but you could build one wrapping the API described above. Also, I would look into whether this is really necessary. If the provisioning engine is meant to be run in the same domain (e.g. on-premises) then you would not need SOAP.
I've been investigating some cloud vendors and the ability to implement single sign-on with them, especially when it comes to AD (Active Directory) integration.
So far I've learned that with Azure this is possible through ADFS and the AppFabric Access Control offer.
In AWS, since it is possible to create a VPN and see EC2 instances as a natural extension of a private datacenter, I believe implementing SSO would be rather simple (not sure if I'm right on this one... Please correct me if I'm wrong).
With App Engine though, even though there is some documentation on AD synchronization (not full integration) for Google Apps, I'm struggling to find out whether AD integration would be possible... Is there any strategy for that?
Any bit of information on cloud apps and AD integration will be appreciated!
App engine apps can only call out to other services using HTTP or HTTPS, so you could not directly query an AD server. Of course, I'm sure you could build a simple HTTP/LDAP bridge if one does not already exist.
UPDATE: oops, I forgot about SDC,or Secure Data Connector. It is not exactly a HTTP/LDAP bridge, but can provide a bridge between your intranet and your Google App Engine app.
You typicially don't need communication between the application (in this case running in GAE) and AD.
You would, instead, get a security token from and STS (ADFS) and then send the token to the app that is would be configured to accept and trust those tokens.
I'm not familiar w/ GAE but assuming it accepts SAML tokens and understands WS-Federation, you can achieve SSO without ever exposing AD or synchronizing any information between AD and GAE (using ADFS for example)
This is a classic identity federation scenario.