I would like to know weather the JOSSO support federated login ( login using twitter, facebook and so on account).
Josso support all this federated login using OAuth. Check for Josso version 2 in josso.org and Twitter supported authentication protocols
Main Features (v2.4.2)
Advanced Administration console
Fully visual configuration, rollout and management Robust Identity and Access Management
A standards-compliant stack that supports a wide range of features Single Sign-On
Simple combined Web and Cloud Single Sign-On Rigorously tested and certified against multiple OS, Database and application servers
Clustering for high availability and scalability
System monitoring Provided via advanced JMX tools and APMs such as NewRelic
User Provisioning Automatic synchronization for aggregating identity repositories and keeping them in sync Desktop single sign-on
Password-free access from workstations to any on-premise or hosted service Deploy anywhere
Public, Private and Hybrid Clouds Multi-tenant and White Labeling ready for enabling wholesale business models Social SSO
Honors social identities from Google, Twitter, Facebook and LinkedIn Support for SAML, OpenID, OpenID Connect, OAuth, WS-Federation support for seamless Cloud/Federated SSO experience
Integrates with most commonly used stacks such as JavaEE, LAMP and MEAN stacks Multi-factor authentication support Windows interoperability
plays nice with Active Directory for native single sign-on Supports LDAP-compliant and JDBC-accessible identity repositories
Advanced multi-tenant branding capabilities Bundled with user self-services SOA security
Provides access control for both RESTful and SOAP web services Self-contained
Runs as an all-in-one server with no external infrastructure dependencies Cross OS and Hardware compatibility (100% Java-based)
Related
Considering the context of building a corporate portal page to host a kind of knowledge management wiki, how would I approach it if I want to authenticate that page with the corporate Windows user authentication system (ADFS Single Sign On)? Can't seem to find good implementation guides.
Your app. should use an MSAL library to talk to ADFS.
There are other examples in the menu on the LHS.
MSAL libraries are available for a number of languages.
I am develop a public Web API which will be used by number of external clients. In the past I have used HMAC for authentication and stored usernames and api keys in a database. We have more than 50 potential external client applications which will consume my API. The requirement from client point of view is, the authentication should be easy to implement, should support most of the web client/technologies (asp.net, angular, Node etc).
This time my organisation is interested in using Azure AD B2C. I am not sure if B2C is the right product for this usecase where external client application will use your API.
Does anyone have implemented azure-b2c in a same situation?? any sample app (API+Client)
B2C is about self service user registration, password reset, etc. with easy integration to things like Sign-in w/ Facebook (and many more IDPs (identity providers)).
Azure AD B2C is a cloud identity management solution for your web and mobile applications. It is a highly available global service that scales to hundreds of millions of identities. Built on an enterprise-grade secure platform, Azure AD B2C keeps your applications, your business, and your customers protected.
With minimal configuration, Azure AD B2C enables your application to authenticate:
Social Accounts (such as Facebook, Google, LinkedIn, and more)
Enterprise Accounts (using open standard protocols, OpenID Connect or SAML)
Local Accounts (email address and password, or username and password)
Sounds like Azure API Management is what you're looking for.
We're getting ready to rewrite an old native windows mobile application that accesses data through a VPN. We'd like the new version (.NET Windows 10 mobile application) to access data through web services that are protected by Okta. What is the best way to do this?
Thanks!
The best way to do this depends on how the web services are protected.
The main thing to keep in mind is that you don't want to store any secrets on the mobile application.
In an ideal world, these web services would be secured with something like OpenID Connect (OIDC), allowing you to authenticate against Okta (the "IDP") to get access to the web services (the "Relying Parties").
However, the real world is messy, where some web services are protected via SAML, OIDC, OAuth, custom headers, etc.
Without knowing more about your setup, my recommendation would be to build against OIDC, using a proxy server (or "API Gateway") as needed to secure your web services using OIDC.
One of my co-workers at Okta has written a sample iOS application in Xamarin that implements OIDC, I suggest taking a look at the ViewController.cs file in that repository.
I'm trying to figure out the right architecture from a mix of current .NET authentication/authorization offerings. One question that I haven't been able to find much online information on: What are the benefits of having ThinkTecture IdentityServer 2.0 federate ADFS 2 (which is authenticating domain users using Active Directory credentials), vs having IdentityServer authenticate users against the domain directly?
For my company, I see only 3 possible requirements for ADFS 2, but I'd prefer to avoid installing it if IdentityServer is sufficient (mainly because it's open-sourced, and therefore more readily debuggable, extensible, and understandable):
Claims-based authentication of corporate (Active Directory) users.
Support for Office365 SSO - there are directions for integrating Office365 with ADFS
Federating external (business partner) ADFS services (we don't currently need this, but I'd like to keep the option open)
Is any of this functionality not provided by, or not easily added to, IdentityServer 2.0?
Well IdSrv does not do Windows authentication out of the box. It would be easy to add forms based authentication for AD users - but Windows integrated (SSO) would be more involved.
IdentityServer is a really good product but:
Only authenticates against SQL not AD
Doesn't have SAML support - useful for third party integration e.g. SalesForce
No rich claims rules language
which ADFS does for you.
#leastprivilege answered the first - the rest are definitely not trivial to add.
Don't have much experience with Office 365 but it sits on top of Azure Active Directory which can be hooked up with IdentityServer - refer Federating IdentityServer with Windows Azure Active Directory.
I am migrating one ASP.NET MVC 3 intranet Website to the Windows Azure and DB to SQL Azure.
On Premises my site uses Windows Authentication to authenticate and authorize the user(By Placing AUTHORIZE attribute on controllers).
It would be very kind of you If you can let me know How to go about the same.Thank You In Advance !
You have two choices here:
Use federated authentication and something like ACSv2. This requires a bit of work to setup a relying party, install ADFS2, etc. However, it is the most robust and future proof option. It is a very good option.
Use something like Windows Azure Connect. That will bring Windows Authentication to the cloud by joining your running instances to your domain controller on-premises. In effect, you have something of a VPN between your cloud instances and your on-premises domain controller. There are some caveats to this model today (requires installing agent on DC for instance), but it would be from a 'just works' stand point, the easiest. Longer term, this is less attractive I believe than option #1.
You can get more details for each of these by checking out the Windows Azure Platform Training Kit.
I should also add that you have no option (today at least) of using Windows Authentication with SQL Azure. You must use SQL authentication there, so what I am talking about here only applies to the web site itself.
I'm very successfully using Windows Identity Foundation with Azure AppFabric Access Control Service to authenticate using ADFS v2.
As well as straight authentication, it gives you lots of flexibility over other claims, such as roles (which don't need to be based solely on AD group membership).
In my opinion, its biggest strength is that there is no communication channel required between the Azure platform and your on-premise AD. Everything is done via the browser. From a security perspective, this means that although anyone can reach your application, nobody can authenticate to it unless they can also reach your ADFS server. Access to this can be restricted to on-premise clients only or via VPN, greatly reducing the attack surface.
Also, because ADFS does not need to be exposed externally, it can greatly ease the bureaucratic overhead of deploying it, in my experience.
Only configuration is required, which although it can be a bit of a fiddle initially, is pretty straightforward once you've got to grips with it. You configure WIF to use ACS as it's Identity Provider and create a Relying Party in ACS for the application. Then, you configure ACS to use ADFS as its Identity Provider. You could configure WIF to talk directly to ADFS, but the additional level of abstraction of going via ACS can be useful.
Once you've done your configuration, using the [Authorize] attribute 'just works'.
Note that if you're using Ajax calls into your controllers, you'll need to take some precautions, as Ajax calls don't handle the federated authentication redirect (or the ADFS Shuffle, as I like to call it), but it's nothing that's insurmountable.
All in all, I'm very impressed with the combination of WIF+ACS+ADFS for transparent Windows integrated authentication.