We have a client that currently use a ERP-system to store all their clients. This is a closed source ERP so they can not change the authentication flow. Right now they have an authentication API that various other APIs use but development is slow. They are now facing a challenge in that they need to bring more systems in and given the current structure this takes time since their APIs are tightly coupled with the rest of the systems. They absolutely wan't to avoid other departments from creating applications with their own authentication simply because they cannot keep their pace up.
They wan't to keep SSO for all their customer systems but have better control which users are allowed to do what.
I have been reading about Azure Active Directory B2C and it seems really great. We use Azure Active Directory (AAD) authentication for our internal applications and it works flawlessly most of the time.
Here comes the two part question:
Is it possible to use Azure AD B2C and still keep users in the ERP? For example if we can connect Azure AD B2C to send a request to a service that responds with user data if that user exists given that the credentials are correct.
Extension of question 1. The current ERP-systems gives the user an access token and refresh token. Is it still possible to use Azure Active Directory B2C in this case? Basically add our own Identity Provider that will refresh the access token when needed. Is this a feasible thing to do and are there any guides in creating this? Perhaps IdentityServer4 could be used or can it be simplified? http://openid.net/developers/certified/#OPLibs https://github.com/IdentityServer/IdentityServer4
Given these words on their website I think it should work:
Support all platforms and open standards
https://azure.microsoft.com/en-us/services/active-directory-b2c/
Yes, it is possible. As Miroslav mentions, you should use custom policies. This requires a ramp up on custom policies which can have a steep learning curve, but essentially you would take the starterpack (see getting started) and you would modify the userjourney to not write to the B2C directory (basically remove this step). Instead, you would do a call out to wherever the users are. This call out can either be an OIDC identity provider or a REST API, which are specified using technical profiles.
Related
I am new to Azure Active Directory and I am bit confused about the concept and its capabilities.
I am developing an API and a native client application that will consume this API. I registered both the API and the client app in AAD and
I managed the authorization of the client application using my Admin credentials (Azure Account). But I still don't get it.
I want the users of my client application to be able to register to the app service and then use it.
Should I handle that myself within the API (user/password in database) ?
Or
programmatically create users in AAD when users signup for my application ?
Which solution is better if I plan to offer more APIs ?
If using AAD is the case I will be grateful if you provide explanations, useful links or code examples if possible.
Your question is quite broad, and is comprised of several questions, so it is hard to answer concisely.
If your users are already in your Azure AD, you should use that as the user store. If however, they are outside of your organization, you could use Azure AD B2C, which contains functionality for selfservice account creation. Or take a look at https://stackoverflow.com/a/16068340 for a suggestion on how to use AAD for public users.
If the users are already present in your AAD, and you haven't set up user assignment on the application in AAD, they can already log on to the application.
You can use role based security to grant users different levels of access to the API methods if you are interested in that.
My company wants to develop something it calls a "Login Broker" for an on-premise desktop application also under development. The on-premise application will make significant use of Azure services (DocumentDb, Table Storage, Service Fabric, etc). Our goal is to be able to distribute the main application without it containing any knowledge of configuration values to reach Azure resources (endpoints, keys, etc). As a user logs in through the Login Broker, the desktop application then becomes aware of how to reach its resources, what permissions that user has within the application, and so on.
So far, my research has taken me in the direction of claims-based authentication (I'm very new to this area), which sounds correct in concept. Once a user logs in, the claims that we want to put into a token would be those specifics I mentioned above, plus we will undoubtedly have other claims that we don't know of yet that we want to assert.
My question is, does my company need to develop a custom login service / broker to authenticate users and deliver a configuration payload, or can Azure Active Directory serve this need in the way I described? Is this the kind of thing that AAD is suited for natively or would this wind up being a shoehorn that we'd rather avoid?
What you described looks like the federated identity, locally Microsoft has the Active Directory Federation Services, in cloud there are a few options:
1) Azure AD Access Control Services - https://azure.microsoft.com/en-us/documentation/articles/fundamentals-identity/#ac
2) Azure AD B2C - https://azure.microsoft.com/en-us/services/active-directory-b2c/
I would recommend to take a look at the Azure AD B2C.
I am using ADAL in order to log in to my app which is being made in Xamarin.Forms against Azure AD. That is all working fine, however I now want to be able to register a new user and to do this need an access token to pass to the constructor of one of my methods.
However, as the user hasn't yet been registered, I need to be able to get an access token from Azure AD without actually supplying any user credentials. I have been told that in a normal web app, I'd be able to send the client id and app key so that Azure AD would know who I was and then send me back an access token but I can't figure out how to implement this in a cross-platform Xamarin app.
If anyone has come across this before, your help would be greatly appreciated.
Thanks.
Use of an app key in a native application is not recommended, regardless sof the dev stack you use to implement it. The reason is that generally devices should not be trusted with secrets. Furthermore, secret distribution is complicated (you can't embed it in the app code).
As a result, ADAL for Xamarin (and all the other flavors of ADAL meant to be used in native apps) does not expose any method for acquiring tokens with an app key.
From a antive app you really need to bootstrap secure communication with a user identity. Once you have that, you can do all sorts of interesting things on the server side (e.g. you API can, given that is running on the server, obtain tokens as an app).
HTH
V.
We have several customer using our web application (not intranet), some customers want their login should be integrated with their organizations Active Directory.
They just want that user should login to their windows account and can access the web application without entering any user credentials.
I have read some articles regarding ADFS, but still not sure how to integrate that or implement it.
Any proposed solution ?
Thanks!
If you develop a .NET based application, Microsoft provides a library called WIF, which is used to communicate with the AD FS in a +- comfortable way (configuration + little code adaptations to get the claims from the authentication message provided by the AD FS).
There are few protocols that both AD FS 2.0 and WIF support, to make the SSO work, the most common ones are (afaik) SAML 2.0 and WS-Federation. Both are built on XML messages, but you are not required to know the details, if you use WIF.
For WS - Federation, the WIF library provides a plugin for Visual Studio, which allows you to configure your site as the relying party with your AD FS.
You CAN use the credentials within your DB to identify users, you can actually customize AD FS's entire login page and authentication events. However the basic installation requires each user to be defined within your Active Directory. You can also use your DB as a claims store (another data base AD FS will use to provide the relying applications with information about users). Note that if you intend to use an AD behind the AD FS, your AD FS service must be able to access it and LDAP query it, which I'm not sure will work for you, if your users login to their local domain that the AD FS is not familiar with.
IF you are not required to support industry SSO standard protocols (SAML 2.0 I've mentioned), I'm not sure implementing AD FS will be such a good solution. It forces you to work in a certain way, which is not always that comfortable.
Your question doesn't explicitly state that whether you are limited to using ADFS for implementing SSO. ADFS is certainly one way of doing this. You may want to look at OpenID-LDAP (was at www.openid-ldap.org, but project is now defunct) and other identity providers as alternatives for implementing SSO.
One alternative is to implement an OpenID provider that uses integrated windows authentication. They can install it in their DMZ exposing that to the internet, instead of ADFS. It may allow single sign on from Internet Explorer and Chrome.
Implementing an OpenID provider is a non trivial matter. You'll have to pay close attention to security. Fortunally, there are a number of frameworks like DotNetOpenAuth that may help you.
When using OpenID, your "cloud" application will act as an OpenID rely and get a claimed identifier amongst other attributes from the OpenID provider. You should store this in your database to uniquely identify the user. You may choose to implement the OpenID provider such that it can also provide your cloud application with the minimal information like email address, the person's name etc.
The benefit of using OpenID is that your "cloud" application can continue to support other well known OpenID providers like Google and Yahoo without much change.
In the end you'll need to ask your customers what technologies they are comfortable with. You'll find that a lack of trust (a business trait) between organizations is more often than not the challenge rather than technology.
More detail needed as per comments.
There's a good source here: AD FS 2.0 Content Map.
The "e-book" is here.
I could imagine one scenario where you bind your cloud application to Azure ACS, your customers install ADFS on top of their AD and federate their ADFS with ACS. That would give you the functionality you require.
Update after comment:
ADFS can only authenticate against AD. It cannot authenticate against a DB. It can get attributes from a SQL Server DB which it can then transform to claims i.e. it can use a SQL DB for authorisation.
If you want to authenticate against a SQL DB, you can two choices.
Create a custom STS
Use an existing "custom" STS like Identity Server which allows this functionality.
I'm developing a WCF service that will host business logic of the application. The application is mostly for intranet, but can be accessed from internet. We have an active directory domain up and running, so I plan to authenticate and authorize users according to their username and groups they are in. This service will be used mostly be an ASP.NET MVC site
So, first question is how to authenticate and authorize users based on their AD profile?
Secondly, I need to store additional info about each user. The problem is that I can't modify AD scheme. The number of added fields is about 10 or so.
Can I somehow use SQL server for profile storage? Of course I can, but how to tie this with AD auth?
You can use WIF for this.
You would configure your WCF service for WIF in the normal way and then use a custom ClaimsAuthenticationManager class deriving from the base ClaimsAuthenticationManager and overriding its Authenticate method. This is a normal extensibility point of WIF. WIF will
get hold of the security token from the incoming request and add claims for each of the relevant AD properties. In your override of the Authenticate method, you will add new claims to represent your extra properties.
The basic use of WIF for WCF services is described here:
http://msdn.microsoft.com/en-us/library/ee748476.aspx
To see how to use ClaimsAuthenticationManager, start here:
http://msdn.microsoft.com/en-us/library/ee748211.aspx
Well, I think you have a couple of choices here, but you will have to carefully consider the implementation.
The primary issue with using active directory authentication is that by default a user's credentials can only be passed successfully between two machines. In the case of a web application, this means that the user's credentials can travel between the end user's machine and the web server, but no further.
However, this behavior can be changed through the use of Kerberos authentication, which essentially allows an authentication ticket to be passed among all of the trusted machines in the chain (i.e. from the web server to the application server to the database, for example). Successfully configuring Kerberos can be extremely challenging, especially if you have had no prior experience with it.
I think your best bet is to configure your web site to accept only Windows Authentication. This means that IIS will perform the validation of the user against active directory. In your ASP.Net application you can pickup the domain name of the authorized user from Request.ServerVariables("logon_user").
At this point, you can log the user on with FormsAuthentication, for example, without requiring them to login again.
You could then either implement the SQL Server Membership Provider or create your own interface to your database for further user validation and extra information storage. We have used both mechanisms, but I prefer the self-built one due to the additional control it provides and, in this case, you won't need a lot of the functionality (password reset, recovery, etc) that the membership provider offers.