What is the best method of securing a REST Web API with the following requirements. The system has an Angular JS frontend with the REST APIs implemented in ASP.net.
There are two "roles" in the system, users will have one of the
roles. One role should allows access to some APIs (call it "VIEW"),
the other role allows access to other APIs
All users are in Active Directory, so if I have a username, I can check what role they are in- Some clients are on Windows boxes, the others are on Linux
I would like to persist the session so I don't have to look up AD for every API call
I would like single sign on. On the Windows machines, I don't require them to enter user and pass as I already can retrieve their username using Windows Authentication.
I believe that Oauth would be my best option.
There are two "roles" in the system, users will have one of the roles.
One role should allows access to some APIs (call it "VIEW"), the other
role allows access to other APIs
For role based authentication, you can use [Authorize("Role" = "Manager")]. The token will be provided by the identity server and will contain the claim as Role.
All users are in Active Directory, so if I have a username, I can
check what role they are in- Some clients are on Windows boxes, the
others are on Linux
If you have ADFS then you can have an Identity server that trusts the ADFS. The ADFS will provide a token which will have the claim for role and your Identity Server will do the claims transformation and will return the same Role claim back to angular app.
I would like to persist the session so I don't have to look up AD for
every API call
For this while requesting the token, you can ask for offline scope so the Identity server will provide the Refresh Token with Access Token so you don't need to ask for AD again and again.
I would like single sign on. On the Windows machines, I don't require
them to enter user and pass as I already can retrieve their username
using Windows Authentication.
For this one, you can have your Identity sever trust the WSFederation for windows Authentication.
So basically you need to setup Identity server that will provide you with the token and the REST API will use that token to verify claims to return the correct information back to the user.
I am not sure what you expect exactly. Anyway, first I'm gonna reformulate your question with requirements:
you accounts and role are in active directory
you want to manage roles based on an active directory group
you want anybody whatever the system (windows, linux, mac, mobile...) to connect on your application using the same authentication
you want to avoid your AD to be hit constantly (not at any call for example)
if the user is connected on an application that uses the authentication system, he doesn't have to do it so again on another application that uses the same authentication system
If these requirements are yours. I believe the only standard (and clean) solution is to use OAuth. I'm not gonna go in detailed description of OAuth, but this authentication protocol is the most standard one on the net (facebook, google, twitter...). Of course as you don't want to use facebook, google or twitter accounts in your business applications but your active directory accounts you'll have to install/setup/develop your OAuth identity provider using accounts of your active active directory server. Your choice will depend on how well you know ADFS protocol and its different flows (code, implicit, assersion) You have two solutions for it:
Use ADFS: install ADFS; it provides a OAuth portal that will work out of the box with asp.net mvc. This uses the code flow of OAuth that is the only OAuth flow supported by ADFS. For roles and its related AD groups, you'll have to map role claims with AD groups. (it's in the setup of adfs, you'll find many tutos on the net). You'll find lot of tutos as well about how to use ADFS with asp.net mvc/asp.net webapi. I mention .net here, but every technology has an implementation for OAuth authentication (nodeJs/express, php, java...).
Use thinktecture identity server (.net technology). This will provide all the foundation to implement a custom identity server with the least effort: http://www.thinktecture.com/identityserver / https://github.com/IdentityServer/IdentityServer3. It contains an addin to plug its accounts to active directory. With this, you can use implicit and assertion flows.
Use oauth2orize (for nodeJs): https://www.npmjs.com/package/oauth2orize. This will permit you to make the same than thinktecture identity server but in nodeJs. Apparently you'll have to make all the wirering with ad manually. With this, you can use implicit flows (not sure about assertion flows).
At application side, most of frameworks can authenticate easily using OAuth with a lot of existing frameworks. For example, even if you make a single page application, you can use adal.js or oidc.js for angular if you use angular. As I mentioned above, all this is taken in charge by asp.net mvc/webapi out of the box but I know it's the case for other server technologies. If you have more questions, don't hesitate as I'm not sure of what you expect exactly.
Related
I'm building a multi tenant Service Fabric Application, that allows a tenant to specify a login type - Identity(asp.net)/Azure AD.
I have an Authentication service that checks to which tenant the user is linked to and then proceeds to check if the username:password for the user is valid, if valid it returns a JWT token to the gateway API/web API that then allows access to the rest of the services on the cluster.
This is further secured by roles to limit actions and data access etc.
Question 1
What would be a secure way to save the app id and secret given by that tenant if they use azure AD?
In my DB and encrypt the info, it would have to be decrypted to connect to the AD(Trying to keep in dynamic).
Question 2
I'm implementing my own sliding refresh tokens to obtain a new JWT after it expires, is there a better/standard approach?
Question 3
Is there a better/standard way to handle this multi-tenant sign in process.
Question 4
Is there a way to have optional claims set on the JWT Subject that would allow access to shared services but prevent access to tenant specific services if the claim value is incorrect?
Edit
Ideally the Roles should not be part of the tenants AD/B2C because they role are dynamic and managed from within the application.
Instead of building your own STS logic, have a look at IdentityServer, a popular and great OSS tool.
For example, have a look here for a multi-tenant example using asp.net core.
It supports adding custom claims to the token, by implementing a Profile Service. Services can be configured to use claims for authorization.
This blog post may also be useful.
I will very strongly advise you ride upon the Azure tenant model and let Azure AD manage all credentials and authentication. In today's world its a very bad idea to store and manage user credentials when there are plenty of Identity Providers available.
Recommended reading:
How to build a multi-tenant app with Azure AD
How to secure a Web API with Azure AD.
Libraries like MSAL.NET will automatically manage token caches and refreshes.
Use roles and groups in Azure AD
Claims in tokens issued can be customized to some extent.
disclaimer: I work for Microsoft
I am working on a Intranet application where i am calling a SAP service from a ASP.NET WEB API, Currently it is working fine with a HttpBasicAuthentication with a predefined user name and password. But now the requirement is to get the logged in windows user's user name and password through ASP.NET WEB API and pass it to the SAP service for authentication? Can anyone help me on this?
1) HttpBasicAuthentication won't apply in this case.
2) Use identity impersonate via the web.config tag (ref Identity Impersonate) to have the current user's identity taken up in api. However this will only work for Intranet based applications and not over internet. For Internet based, you will need to have Kerberos bridge (somewhat complicated) concept implemented.
3) In you app.start method, you need to set the current principal to windows principal.
Then you can have the user detail available..
Please note that you will not have the user's password available as OS protects that very very securely. You can get the user's Kerberos token though which your target system can auth against the AD being used.
I have a .NET Web API with a bunch of end points/methods that an Angular App calls. I want to now implement the login system against our active directory, and wondering what my options are.
Back in the days, it was simple: windows or forms authentication, and then just some simple configuration in the web.config, and may be a custom provider. But now it seems like there are a lot more options with OWIN, OAuth, token based authentication, etc.
Where do I start? I have a form with username, password, and a login button on the Angular app, and I have the active directory in the backend. What should happen after the user hits the login button? Any direction would help.
Thanks.
Well, it depends on what you actually need.
If you want to authenticate only AD users then you can try authenticate in AD on their behalf and in case of success you return either token or authentication cookie.
But I don't think it is a good idea to make users use their domain password unless you have two factor authentication.
It's better to extend AD schema with additional data for authentication through your service or even to have standalone auth server with associated domain user info. Look how it is done in SQL server (but in reverse direction): you need to define internal user corresponding to domain login. This approach allows you to have users that do not belong to AD, sometimes this can be important for outsourcing some tasks.
Look at IdentityServer
I am relatively new to uisng ADFS (in ASP.NET) which is what my company wants to use and just have a few basic questions about that:
Am I correct there is no explicit "Authorize" call you can do like with ASP.NET Membership Providers? Unless you on a domain it presents you with a login screen and once you enter credentials it does validation and returns back a token with claims information.
Can you configure some forms to allow anonymous access like you can do with Forms Authentication?
Thanks.
Yes, you can setup pages in your app that don't require authentication. It works exactly like you'd do with Forms Auth.
On #1: in a claims based model, your app relies on an external system to authenticate users and receives evidence that the user is valid in the form of a token. You can completely automate this (using WIF and config files), or you can explicitly trigger the authentication process. In any case, your app won't be responsible for validating legitimate users anymore. It is a responsibility that it delegates to the STS (e.g. ADFS). That's why apps are called "relying parties".
I'd suggest you read the first couple chapters of the A Guide to Claims based Identity for a better understanding of the underlying principles.
We are running a Saas ASP.NET 3.5 Web application using Forms authentication on a IIS 7.5 public server with protected content for thousands of users. We also have some subapplications running ASP.NET MVC 2.
Usernames and passwords are stored in our database and every user has roles and groups attached, with privileges and access rights defined.
Now we have been asked to also facilitate for simple SSO login via Active Directory so that users do not have to enter username and passwords twice to login. These users will originate from different networks and domains.
No user "sync" should take place from our servers to LDAP serves. We are not sure that any communication with LDAP is needed since all users will be created in our system and maintained there. Forms authentication will be used for most of our users.
From here on we are unsure which is the best path to choose. For our scenario what would be the "best practice" way to proceed?
The simple answer is SAML. It is considered the "best practice" and many large SAAS providers support it.
SAML protocol defines the single sign on flow between multiple systems. It establishes trust between systems using certificates. Your application accepts an assertion containing attributes (user id, name, email address, etc.) from other systems. Your app will map the user into your user store.
In .NET world there are several options. You can find a library that implements SAML (ComponentSpace has one) and hook it into ASP.NET authentication. You can create your own using Windows Identify Framework (WIF). Here's the boatload of WIF videos http://www.cloudidentity.com/blog/2010/06/23/ALL-WILL-BE-REVEALED-7-HOURS-RECORDINGS-FROM-THE-WIF-WORKSHOPS/. You can try IdentityServer http://thinktecture.github.io/
Depending on how secure your app must be, you can opt for a simple option of passing user id from trusted networks using a simplified method. I've seen apps that allow user id to be sent via URL parameter or form field. Of course, this is horribly insecure, and you are taking on more risk, because the trust between two networks is not cryptographically enforced. You can mitigate it somewhat by checking referrer string or IP address (if you can isolate IP range of a corporate network for example). But you are still open to spoofing because any user can impersonate others by simply replacing user id within HTTP request.
It probably doesn't answer your question fully, but hopefully points you in the right direction.
I recommend looking into ADFS 2.0 it is very powerful in terms of claims mapping and works with AD: http://msdn.microsoft.com/en-us/magazine/ee335705.aspx
What you would make is a token consuming portion of your app that would receive and parse the final claims returned to your web server after the authentication loop.