I'm mid-way through a task to migrate a legacy .NET MVC app to use Single Sign On (SSO) to make integration with a to-be-developed mobile app possible. I'm planning on using Azure AD B2C to facilitate this and based on my researched, I need to use custom policies to achieve the required functionality.
Work on this migration is proceeding very slowly. I'm finding the custom policy XML very clunky to work with. It's going to take quite some time to achieve parity with the existing system given the current velocity. I'm wondering whether it would be wise to sidestep a lot of the migration headaches by using the Microsoft Graph API in place of custom policies.
Take registration for example. It appears common to redirect the user to a SignUp.xml custom policy (or the integrated SignUpOrSignIn.xml) to handle adding the user record in the AD B2C data store. Part of this policy would involve calling a REST API to create a corresponding record for this user in the app's database (stores email settings and such). Instead of using these custom policies, my plan would be to instead take the existing registration process and simply add a step which creates the user record on the B2C side using the Microsoft Graph API.
It appears like most things I need may be achieved using the Microsoft Graph API. Things I'd need that I can see are not available are:
logging in to a user account and;
sending verification emails
Are there any other common authentication-related tasks I'm likely to need that couldn't be achieved using the Graph API?
As far as downsides, the fact I'd be handling user passwords (even if it was just to create the user and nothing else) is an obvious concern, but perhaps acceptable. The main thing I'm after is a simple SSO solution that generates secure access tokens (incl. handling reset tokens, etc). I hope then, that this could be a feasible option.
You will miss out on password reset, profile edit, SSO and token expiration etc.
A better way may be to use the base custom policies and achieve a lot of what you need by having the policy call REST API's.
What is your use case?
Related
I have a microservice architecture, where one Single Page Application accesses three different APIs:
I am securing those APIs via the Microsoft Identity Platform and therefore I also need service principals.
My first approach matches with all the examples I found on blogs or in the MS docs.
In this case I have one app registration for the client app and three additional ones for the APIs:
This has the following impact:
Each API has its own audience.
I get four service principals for each application.
I get three different places where I have to administrate the user assignments to roles. (for example: User A can read assets from API A etc...)
This works, but comes also with some problems:
The other admins that are managing which user is allowed to do what are confused about three different places they have to assign roles. It would be nicer to have one central place.
The roles of the users are not placed in the ID tokens, because only roles of the client application would go there... but I do not want to assign permissions in the client app again.
If API A wants to call API B or C, I need two access tokens for other APIs.
This lead me to a second idea:
Here I have one registration for all 3 APIs. This already solves problem 1 and problem 2. But it also gives me a strange feeling, because I never found other people doing so.
Also my ID tokens are not telling me the roles, so to fix this, I could even go another step further to a single app registration for everything:
Now one registration exposes an API and consumes this API also. Something what is possible and seems to solve my problems. I even get all roles for the users in my ID tokens AND in my access tokens now.
However, this is contradictive to all other examples I found.
Which disadvantages does the last solution have?
Which of the three approaches should I chose?
Which disadvantages does the last solution have?
One thing that comes to my mind is that you want API A to be able to edit data in e.g. MS Graph API, so you give it the app permission to Read/Write Directory data.
Now with the shared app registration this permission has also been given to API B and API C.
So the principle of least privilege may be violated in the second and third options.
But it does make it easier to manage those APIs as you noticed.
The third option does open up the door for the user to acquire access tokens to any APIs that you might want to call on behalf of the current user from your APIs.
So if you wanted to API A to edit a user through MS Graph API on behalf of the user, you'd have to require the read/write users delegated permission (scope) for your app.
This would allow the user to acquire this token from your front-end as well, even though that is not intended.
Now they would not be able to do anything they wouldn't otherwise be able to do since the token's permissions are limited based on the user's permissions, so this might not be a significant disadvantage.
Which of the three approaches should I chose?
As with many things, it depends :)
If you want absolute least privilege for your services, option 1.
If you want easier management, I'd go with option 3 instead of 2.
There was that one thing I mentioned above about option 3 but that does not allow privilege escalation.
I'm writing an application that will be the backend for a react website. The website is to be used by our customers, but we will fully control the permissions of the user. We have decided to use Azure AD to secure requests, but will also be exposing the API for end users to use directly if desired.
My understanding is in Azure AD I will have to create an application that will allow web based implicit authentication (for the react site), as well as a native application that will allow a dameon based application to authenticate to the API.
This I believe means I will have two audience ids in my application.
I'm trying to get claims to include groups, and I can see if I edit the meta data of both applicaitons in azure AD to include "groupMembershipClaims": "SecurityGroup" I can get claims with the group IDs in, but no names.
I think I can also use appRoles to set roles the application uses, but I've yet to get that to come through as claims in the JWT, but I'm assuming it can be done, however I'd need to setup the roles on each applicaiton, then add the user twice which isn't really ideal. I also think that because my app is multi-teanated that external users could use this to set their own permissions, which isn't what I want to do.
Sorry I'm just totally lost and the documentation is beyond confusing given how frequently this appears to change!
TLDR: Do I need two applicaitons configured in azure ad, and if so whats the best way to set permissions (claims). Also is oAuth 2 the right choice here, or should I look at open id?
Right away I gotta fix one misunderstanding.
Daemon apps usually have to be registered as Web/API, i.e. publicClient: false.
That's because a native app can't have client secrets.
Of course the daemon can't run on a user's device then.
Since that's what a native app. An app that runs on a user's device.
This I believe means I will have two audience ids in my application.
You will have two applications, at least. If you want, the back-end and React front can share one app (with implicit flow enabled). And the daemon will need another registration.
I'm trying to get claims to include groups, and I can see if I edit the meta data of both applicaitons in azure AD to include "groupMembershipClaims": "SecurityGroup" I can get claims with the group IDs in, but no names.
Yes, ids are included only. If you need names, you go to Graph API to get them. But why do you need them? For display? Otherwise, you need to be using the ids to setup permissions. Names always change and then your code breaks.
I think I can also use appRoles to set roles the application uses, but I've yet to get that to come through as claims in the JWT, but I'm assuming it can be done, however I'd need to setup the roles on each applicaiton, then add the user twice which isn't really ideal. I also think that because my app is multi-teanated that external users could use this to set their own permissions, which isn't what I want to do.
Your thoughts for multi-tenant scenarios are correct. If you did want to implement these though, I made an article on it: https://joonasw.net/view/defining-permissions-and-roles-in-aad.
Why would you need to setup the roles in multiple apps though? Wouldn't they only apply in the web app?
If the native app is a daemon, there is no user.
Overall, I can see your problem. You have people from other orgs, who want access to your app, but you want to control their access rights.
Honestly, the best way might be to make the app single-tenant in some tenant which you control. Then invite the external users there as guests (there's an API for this). Then you can assign them roles by using groups or appRoles.
If I misunderstood something, drop a comment and I'll fix up my answer.
Azure AD is of course a powerful system, though I also find the OAuth aspects confusing since these aspects are very mixed up:
Standards Based OAuth 2.0 and Open Id Connect
Microsoft Vendor Specific Behaviour
ROLE RELATED ANSWERS
This is not an area I know much about - Juunas seems like a great guy to help you with this.
OAUTH STANDARDS AND AZURE
I struggled through this a while back for a tutorial based OAuth blog I'm writing. Maybe some of the stuff I learned and wrote up is useful to you.
AZURE SPA AND API CODE SAMPLE
My sample shows how to use the Implicit Flow in an SPA to log the user in via Azure AD, then how to validate received tokens in a custom API:
Code Sample
Write Up
Not sure how much of this is relevant to your use case, but I hope it helps a little on the tech side of things...
I'm learning about developing APIs with rails, but I can't find how to secure the base methods like user creation. Let's say I have a rails backend API and a frontend mobile app. I want the app to be able to make API calls to create a new user. Off course, not everyone should be able to create a new user, so it should have some kind of authentication. I could use basic or digest authentication (doesn't really matter, because I'll definitely use SSL), but then I would have to hardcode the credentials into my app. If the credentials are discovered somehow, I would have to change them, but that would mean that all instances of the app are no longer authenticated and they can't create users anymore.
The things I would like to have:
Only my apps should be able to use the user creation calls.
It should be easy to change the credentials, or the credentials should change automatically over time. If they would involve the date and time for example, it would be harder to crack.
It should be impossible (or VERY hard) to beat the system behind it, while having knowledge of a couple of the credentials over time.
Would it be possible for example to let my apps generate public and private key pairs at random and use them? What's the standard way of securing these calls?
Thanks in advance,
Rugen Heidbuchel
I could share my own experience:
https protocol communication with API. That is your last sentence about private/public keys, all is built in into https.
Doorkeeper (we combine it with Devise) gem for Oauth (github accounts in my case) as authentication, while you can use pairs of user/passwords instead.
CanCanCan gem as authorization (User creation restriction is about authorization and not authentication)
Set of that three tools should provide essential security level for your API. I believe cancancan could be under discussion, while devise is mostly industry standard.
What are the pros/cons of using .NET Identity 2.1 versus Azure Active Directory (Premium)?
We currently have an MVC 5.x application using Identity 2.1 for registration, sign-in, password resets, etc. A Microsoft consultant is suggesting we should swap to Azure Active Directory to remove the complexity of "maintaining your own security".
What are the reasons to make the swap and why wouldn't you?
I wouldn't say the two are mutually exclusive. Asp Identity has that functionality built in but you don't have to use it. Actually, you could create your own userstores, managers etc. that poll the azure AD for this info. Identity allows you to use it, override it, or skip it entirely.
Why you wouldn't want to do this? Not everyone has AD. Not everyone needs it. The bare-bones approach that the templates use are simply application managed users and claims.
If you are targeting multiple applications and want SSO and have AD then you can take advantage of it. Developing your own at this point is redundant and more work/maintenance as the consultant pointed out.
You will still probably have a Users table and possibly others in your app database because you may have business functions unrelated to AD but boilerplate stuff would all be managed via AD.
Another issue you may run into is the need to authenticate app specific users outside your AD. At that point you may choose to implement a mixed solution. One half polling AD for internal users, and the other falling back on Identity for external users.
UPDATE: I failed to mention earlier that we want solution that will be flexible with authenticating users from within our databases or by asking other servers to tell us if the user is authenticated. It is also worth mentioning that these other servers are not under our control so we can't enforce a specific user model.
I had a long and hard read on OAuth and OpenID but they are both not a suitable solution for our situation and will make the process harder to the user. This is something that has been solved a thousand times, yet I cannot find the solution.
What we are looking for is a framework that can be used in a REST services server to authenticate users (no third-party clients involved) with their username and password.
The solution must not pass the username and password except the first time on login and use tokens for further authentication. Even though OAuth does use tokens, it is designed to allow third-party clients access to the service-providers resources. That is not the case here, the services are for our own application only, the only thing needed is user authentication.
What do you guys think is the most appropriate solution?
Configuration:
-Spring server that provides RESTful services with our thinking going towards using Spring Security with some user management and token management framework.
-iOS Device that will be making HTTPS calls to the server.
What we ultimately want is to have the device send a login request and receive a token if the login was successful, later on make requests using that token. Just like Facebook, excluding third-party involvement.
Is there something that is ready to be configured in our server? Or should we consider building our own token management, comparison and generation software?
Is using Spring-Security with an iOS application without involving storing cookies or redirecting to pages possible?
OpenStack offers as part of it's many projects related to open source cloud... the project Keystone. Which does this pretty much exactly what you want.
You might want to check it out here:
http://docs.openstack.org/developer/keystone/