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.
Related
I have created a tenant and application to be able to authenticate users via Azure B2C. I have a front-end application in React which uses Msal.js with authorization grant to obtain the access token, which is then used to make requests to a webserver which acts as a resource-server (connected to Azure b2c as well). I have used this answer to make it work -> How to secure Spring Boot REST API with Azure AD B2C?
Apart from that I have few daemon applications which need to connect to the backend as well. They should use client_crendentials grant_type to connect to the backend server (which is a resource-server).
However, the token that is obtain by the daemon app, cannot be used with the backend server (resource server) for some reason. Is there something that I do wrong ? Do you have samples for this scenario ? I've already spent days looking over all the documentation to find where is the problem.
I have an existing App Service in XYZ tenant. Previously my API was in XYZ tenant and using that App Service of same Tenant, now I have moved my API from Azure AD of XYZ Tenant to azure AD B2C of ABC Tenant. can I use existing App Service of a different Tenant(XYZ) in this scenario to publish the API. Can App Service be a multi-tenant.
Thanks!!
Per my understanding your app service which hosting your APIs is under subscription of XYZ tenant and use Azure AD App in this tenant to auth your APIs. And now you want to use Azure AD B2C App in another tenant(ABC tenant) to protect your APIs .
Yes, of course you can do that.You can use Azure AD apps belongs to other tenant(including Azure AD b2c tenant) to protect your APIs hosted on App Service . Which Azure subscription that your App Service belongs to just means you will be charged on that subscription, it has nothing to do with the business logic with your code on app service.
If you want to do so , at the code level , there will be some differences compared to using Azure AD applications if you use Azure AD b2c applications to protect your APIs .
This sample page will be helpful for you to modifying your codes : https://learn.microsoft.com/en-us/azure/active-directory-b2c/code-samples
If you want to design your APIs as multi-tenant by Azure AD b2c, this doc will be helpful : https://learn.microsoft.com/en-us/azure/active-directory-b2c/active-directory-b2c-setup-commonaad-custom
If there is anything unclear , pls feel free to let me know and if my suggestion is helpful , pls mark me :)
Our current API use seesionID for the authentication. We plan to use Azure API management to manage our web api. However Azure web api management has their own authentication. How can we link those two together. Our customer can use the same logon information.
Conversations about authentication and identity in Azure API Management can get tricky because there can be three different identities and then there are the different contexts of runtime requests vs management requests. So, to be sure I'm answering the right question, let me try and get some terms defined.
The three identities:
API Provider: This is the Azure user who has created an API Management instance.
API Consumer: This is a developer who is writing some client software to consume the API.
End User: The user of the application written by the API Consumer and will be the one who actually initiates runtime requests to the API.
I am assuming that you are the API Provider. What I'm not sure about is whether your customers are the API Consumers or the End Users.
Azure API Management provides identity services for API Consumers. Consumers can either manually create a username/password account or use some social identity provider to create an account. They then can get a subscription key that will allow Azure API Management to associate requests to the API Consumer.
I think you are asking if you can connect the sessionID, which I am guessing you use to identify End Users, to a subscription key used to identify API Consumers. If that is correct, then the answer is no (except for the scenario described below), because we need to identify the API Consumer key before any policies are run to ensure we run the correct policies.
You can change our Api Consumer subscription key. So, if you only have a low quantity of customers/End Users you could create an Api Consumer account for each End User. However, you would only be able to map sessionID to API Consumer Subscription Key if sessionID was a constant value. I'm presuming based on the name, that value changes at each login.
Although Azure API Management provides identity services of API Consumers, it does not provide full identity management for End Users. We leave that to external partners like Azure AD, Thinktecture Identity Server and Auth0. I'm assuming that your existing system is already using some kind of identity provider to generate the sessionId. What you can do with Azure API Management is validate that sessionId using policies in the API Management Gateway. To do that we would need to know more about the format of the sessionId.
Sorry for the long post but it is a confusing topic and I wanted to be as clear as possible.
I have several Web PI endpoints currently secured with an access key. I'm not opposed to abandoning this security model.
Now, we're building a web app that will consume the services. The front end will have a login screen to secure portions of the application. I also want to make the Web API services available for use by applications other than our own (think public API).
How should I secure my services and allow access from our own web UI and as a service?
There are many ways to secure Web API 2.0 endpoints.
It seems like you already secured your endpoint with an access key, no idea how your clients know the access key.
For your web app I would ask:
How is the user logging in as you described? What authority are they providing their credentials to? Can you use that authority to attach a token to the requests of your web service?
You mention you also want to provide a public access through a public api. What credentials will they have? What authority will they request access from? You could set this up many ways with different types of credentials e.g. user name and password/client certificate/access key.
Microsoft has some really good resources about this including:
http://channel9.msdn.com/Shows/Web+Camps+TV/Securing-ASPNET-Web-APIs
http://www.asp.net/web-api/overview/security
I can think of:
HTTP Basic Authentication
OAuth/OpenID Connect
Client and Server Certificates
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)