I am building an application using azure mobile services, where I have used azure authentication services for user authentication. Each user can store some of their information. I want to add more than one admin who can manipulate the information of all user when needed. I also want to provide admins a separate front-end. Is it possible to implement. If possible kindly provide me some resources.
Mobile Services on it's own doesn't have any concept of what an Admin is in your application. For that reason, you'd have to design the admin system yourself. You can do this in a few different ways including:
Create an Admin only app that the admin's use and send the Mobile Service Master Key over in the headers. This will make the user.level property return "Admin" while user's who are just authenticated to your app will have a user.level property of "Authenticated". You can use this in your server scripts to basically say "If admin, do THIS, otherwise if authenticated, do THAT".
You can create a Role table in your database and check if the user making the request is an admin for reach request. If so, you can then use similar server side logic above to perform specific logic for the admin vs the non-admin.
If you know the specific user IDs of people who will be admin's, you can just check against the user making the request in your server side logic (the advantage of this approach is that it doesn't require an admin only app or an additional check against the database to see what the user's role is).
Again, Mobile Services doesn't have a concept of an admin as far as your users go (only the sense that if the Master Key is sent in the request is "from an admin") so that's something you have to put in place yourself.
Related
While developing an on-premise, intranet-only REST API server for my company, I managed to completely confuse myself regarding authentication issues.
I have:
A REST web server implemented in C#, using self-hosted Nancy, running as a Windows Service
A C# client that can query the server, run by a user in our company
I do not have:
Any form of access to our Active Directory and/or domain controller, apart from what any application running under Windows normally has
Any way to influence AD settings or configuration
Active Directory Federation Services (ADFS) (I think. We use Windows 7 and Office 2010, just to give some perspective on the state of the software landscape)
Azure Active Directory (AAD)
I want:
A way for the server to authenticate that a request is made by a user of our company
It is perfectly fine if the client has to sent some additional authentication data with each request, as long as it does not contain the user's password in any form
I do not want to:
Have to set up any additional software (my server must be minimum configuration and maintenance, so the average user can install and run it)
Install / configure / maintain an IIS server (see above)
Use ASP.net (way too big for my needs, plus see above point(s))
Handle user passwords in any way (company policy and common sense)
Impersonate the user (I only need to validate the authenticity of the request)
Implement my own user account database. We already have half a dozen services that need their own username/password combinations, I do not want to add yet another one
I have read articles that show how to use Windows authentication with IIS, or how to use Azure Active Directory (AAD) with Nancy. Other questions here have already informed me how to authenticate username / password combinations against the Active Directory. However, none of these satisfy all of my requirements or have requirements of their own (like AAD/ADFS) that I cannot meet.
It seems that Kerberos/SSPI might be what I want, but it seems very involved and quite complicated to get working with C#. It is possible I will have to go this route, but I could really benefit from some minimal working example (the accepted answer provides a C# implementation/wrapper, including an example project, but I can't seem to be able to make heads or tails of it).
Maybe I am naive, but what I image the solution to be is something along the following lines:
The client queries a service (AD, Domain controller, ...?) for some form of authentication token, using the credentials of the currently logged in user
The token is then sent to the server together with the username, as part of the request that needs to be authenticated
The server extracts the token, and queries the same service (AD, Domain controller, ...) whether the token is authentic, valid and belongs to the user in question
Is this possible at all? Ideally, with some sort of ready made library that I can plug in to my projects (I'm reaching, I know)?
You can do this with stateless authentication and Jwt. Send a username and password to "/ auth" (example) and "/ auth" will search the AD (example) and validate if the user exists, then create a Jwt token with the name of the user on load. When you make a request, you will only send a Jwt token and Nancy validates the token.
We have an application (C# on the server, using AngularJS / Web Apis for a single page application) that assigns users different roles, which are stored in the database. When the user logs in, the user object (including RoleID's and RoleName) is transformed into a JWT and sent to the user, which is then used as authentication.
We're having trouble determining the best way to maintain and use these access roles however. Specifically, to use them in the current set up, it would seem that we have to hard code either the name of the role or the ID into the application.
For example, on the client side, if we want only users with a Manager role to be able to see and click a button, we would have to explicitly state that, ie if (UserService.HasRole('Manager')) { doStuff(); }.
Conversely, we'd have to do the same thing on the server side (because everyone knows relying on client-side security is bad). When the server gets a request on the API, it checks the JWT for validity and, if valid, checks the User's roll to see if they are allowed access to the specific web API endpoint.
This all seems prone to breaking if a role is renamed, or the ID changes. I generally hate hardcoding things like this. Is there a better methodology or approach that can be taken here?
In the past, when we've done RBAC (Role Based Access Control), we decouple the Role from the Permission e.g.
Role Permission
===============================
Manager Create Order
Manager Delete Order
Till Operative Create Order
Administrator Create User
Administrator Suspend User
etc.
This could be stored in a database and cached in something like Redis. Two tables, Role and Permission, where the Permissions need to match the ones built into the application (you could script this).
So your permissions grow with your application e.g. you add a new dining service, you can add a "seat diners" permission. The permissions for existing/mature bits of the software should rarely change (unless they were written incorrectly), whereas the roles are entirely fluid and can be renamed etc.
You can then use an annotation/security framework to ensure that the user making each API call on the server side has the correct role required.
You can even make it additive and allow a user to occupy multiple roles at once to blend things together.
You may maintain your user to role mapping in the database also in another table (using FK constraints) or you may use something like LDAP with the mapping being looked up from the DB/cache.
On the server side, Microsoft has built in management for roles. I would first look at
http://www.asp.net/identity/overview/getting-started/introduction-to-aspnet-identity
And then I'd also look at the the IdentityServer project for working with JSON Tokens on the server side.
https://brockallen.com/2013/04/14/getting-json-web-tokens-jwts-from-adfs-via-thinktecture-identityservers-adfs-integration/
On the client, I would suggest storing the tokens as either just in memory javascript or if you want them to persist, I would store them as cookies but make sure to set the cookies to not be accessible by JavaScript by using the httponly parameter when creating the cookie.
HTH's
I have an Azure webapp that's managing it's users via Azure AD. I want the users to be able to register in my Azure AD directory to create an account (self-service), so I gave the app read-write access to the directory and setup a page using the Graph API to create the users.
Until here, everything is great. But the problem I have now is that I want to enable multi tenancy, so users of external AD directories can login to my app. This works, but I need to login as an administrator for the account because it also asks read-write access to their directory.
Is there a way to fix this? I only want read-write access to my directory to be able to create user accounts. I don't want to ask permission to touch their directory because, most probably, they wouldn't trust my app.
Thanks.
I found a quick and dirty solution: Add another app to the Active Directory. This app should be single tenant and have only permission to read and write the active directory. We can the use this app's credentials to access the Graph API and the other app's credentials to authenticate users.
I wait to see if someone has a better solution for this scenario...
sorry for the late response here. In general, an operation to create objects in a directory (like users) requires admin permissions. Also it looks like the web app you are creating uses app-only permissions, which definitely requires admin consent. In the multi-tenant case, the admin of the consenting tenant must be the one to consent to this type of app - only someone in this role really has the authority to grant consent for this level of access.
Hope the helps,
No need to use a secondary app in lieu of the authentication role - - there may be some peculiar side effects on the authenticating user anyway such as extraneous / incomplete logging, role inconsistencies, and missing system / internal references.
What are you using for login credentials for your app (TenantID etc.)?
AD is very strict in credential management, so I would go back to the app structure.
At the query level, you could make all tables entirely separate per tenant with no shared table data and include a multitenant identifier column so no one can sql inject if you were sure to include the multitenant identifier as an explicit variable.
Then in an entity model, you could inherit a multitenant interface for everyone which referred back to the tenant identifiers (as a part of EF).
This way the burden is isolated to OAuth or other libraries on top of that to take care of the third-party authentication.
For the past 2 years we have created 3 desktop application and 2 admin section(web) for one of my client.
Every application uses its own authentication process.
I have merged the authentication process for web in single unit.
But the client wants to have one screen for getting authenticated on desktop application as well as on website.
he also want to use different browser and the username /password should be asked only once irrespective of browser opend.
I tried to use cookies for web. but every browser has got its own cookies.
Can any one suggest how can i authenticate a user for the whole computer so that authentication information is available to desktop application as well as to website irrespective of the browser being used?
Edit: As suggested by joe using windows authentication is not possible in my case.
So i created one more table with following column
ip,userid,authenticatedat
when ever a user is authenticated i insert its ip,userid, and time in table.
when ever a non authenticate user comes first i look in the table if the ip is present and authenticatedat is within 30 min i assume user is authenticated and set the session/variable with data required.
This i have checked and found it is working .
I have found this is not secure.
Windows authentication is the only way I know of doing this. Assuming your users are on a domain you control, then their Windows credentials would validate them, and they wouldn't ever need to enter a username and password.
Outside of that, I can only think of hacky dirty methods of making this happen. You could install a single authentication service on their machine which is available to connect to remotely from other applications - those apps would call your service, and that service would authenticate the user and pass an authentication token back. Easy enough for Windows apps, but making that work on a web app wouldn't be fun. Your web server wouldn't be able to talk to this service, so you'd have to rely on the client javascript talking to the service and retrieving a token or hash, and then the javascript passing this on to the web server.
Anything you put on a local machine, you have to assume the user can reverse engineer and manipulate, so if you need real security, I doubt you'll find a solution. Best bet is just to make the user log in every time you need to, and have your authentication/authorization code on your web service layer.
I have written and deployed a custom security extension for SSRS 2008r2 and it works beautifully apart from when trying to deploy reports from within BIDS 2008/Visual Studio.
The architecture for the security extension handles logins via multiple authorities and I manage this by creating a user session in LogonUser(), persisting this in a database and then loading the session in the client proxy class for the RS web service using a UID passed by cookie from the service, then rewriting the authentication ticket to contain the session UID plus user roles for the current user. These values can then be used in the custom authorization extension to manage user permissions on SSRS actions and objects.
The problem I have run into is that it does not work when deploying reports from BIDS. Its accesses the service directly and therefore the service proxy class is not required. I have tried handling the post-authentication event on the HTTP context but alas the session cookie is not persisted by the RS service so I cannot access the session values.
So what am I missing? Is there another method for controlling user roles & permissions that does not require hard coding usernames anywhere? Like I said, logins can be made using multiple authorities so managing permissions via just a username is not possible (and the thought of it makes me cringe).
One possible solution I thought of is writing an extension or plugin for BIDS that essentially acts as a proxy for the web service which would allow me more control over the login process, but I have no idea if this is possible (google is no help...)
Any help would be gratefully accepted!
Are you using the IAuthenticationExtension interface? The following link provides a sound example of access control if that is what you require.
http://blogs.msdn.com/b/jameswu/archive/2008/07/15/anonymous-access-in-sql-rs-2008.aspx
I would imagine that the nt username can be tracked here and then lookups made against active directory groups etc. The main headache I can see here would be enabling the correct trust policy in the ssrs policy configuration.
Well I gave up on finding an elegant solution so I have gone down the road of least resistance and followed what I gather is the SSRS guideline of having a 'master' account, which I will specify is to be used for report deployment and subscriptions. This account will need to be hard coded in or pulled from a settings file I'm not sure if there is any other way. Cheers.
Update: I have gone down this road and it works fine. If a user is logged in through the web front end they can deploy reports there, but if they want to deploy from the development environment (BIDS) they need to log in using the master account when it the login dialog shows. I have restricted the deploying account to only this specific use.