We have a mobile web platform that we are developing above Azure.
We have a website which is a regular passive authentication scenario and mobile client infront of a web serivce which is active authentication scenario.
We want to create our own users identities store and not base ourselves upon others , currently he are the options we mapped and I have added questions regarding them:
(Correct me if I am wrong or writing something silly).
1.Asp.net membership -Was not originally built for active scenario also will block us in the future if we also want to support OpenId/OAuth providers.
Also , does not support SWT/SAML tokens , so in the future we will need multiple security handlers in our services environment.
Do you know any good way to integrate this with Azure ACS if we need to in the future ?
2.ADFS 2.0 : We can install active direcotry on a virtual machine and manage all users through that , in the future we can integrate this to Azure ACS , supports SWT.
Is Active Directory not an overkill for basic users authentication ? Wont it be an IT overhead (something we desperately want to eliminate) .
3.We can perhaps install other identity management servers - such as Oracle Identity management , again , on a virtual machine and integrate Azure with that as custom STS.
Oracle has designated web access products line :
http://www.oracle.com/technetwork/middleware/id-mgmt/overview/index.html
4.We can use Azure service identities , and simply add users to there. Our main question here is if we can add large amounts of users to this scope (more then several millions).
Regards ,
James
I would suggest making your own STS, but maybe use OpenID or Facebook or someone to do the authentication. Or you could do something like this to store your own usernames, etc:
http://www.soulier.ch/?p=1105&lang=en
But you will run the risk of storing these credentials and have to make sure you don't store it in a way that could be compromised. I don't think service identies would be good for that volume of users.
You may want to check out:
http://identityserver.codeplex.com/
http://garvincasimir.wordpress.com/2011/08/06/azure-acs-plus-asp-net-mvc-memberships/
Related
My goal
overall goal
I want to serve various applications running on docker containers hosted on the same server, each on a subdomain of company.com. And I want only people from my organization (Microsoft AD azure) to access subdomains, in some cases even only people having specific AD groups.
goal specific to Keycloak
I simply want to have specific realm roles have access to specific subdomains, and nothing else. And this, using only a single realm client (see further for explanation).
what I have achieved to do
I have linked several applications on a server and serving each using traefik on a specific subdomain. For example app1.company.com and app2.company.com.
I have also made a middleware so that all routers using it will make sure users must login. I have used a thomseddon/traefik-forward-auth container that I called oauth. I am using Keycloak and I have successfully linked an Azure Active Directory as identity provider. For this, I enabled a single-tenant application and used its client id & key. I also mapped successfully some AD group to a Keycloak role.
Within oauth configuration, I have added the client id & secret from a single keycloak client rather than from the azure application. I believe this is mandatory if we want to use traefik to redirect trafic.
Now, only people from within my organization can access each app. Success!
Some documentations I used
Homelab Single Sign-On & TLS
How to Configure Microsoft Azure Active Directory as Keycloak Identity Provider to Enable Single Sign-On
what I want to do
Each application has its own subdomain. However I cannot figure out where to make it so that some subdomains are accessible only if a user has a specific realm role (linked automatically depending on a AD group thanks to the above-mentioned mapper).
I thought of adding resources within the Keycloak client, but I don't find how to do it using subdomains.
other alternative is to make one client per subdomain, but this means I need to run one oauth container per subdomain... This seems overkill & a waste of resources without counting maintenance.
The only relatively simple solution I found was to create one Keycloak client per type of permission rules (aka Roles in Keycloak) I wanted.
Then for each type, I had to make a traefik-forward-auth container and connect it to each Keycloak client. I am still using the same Identity provider, so once you've configured it to generate roles, you only need to tell which roles may use which client.
To give an example, you want to have 3 types of permission rules: one for admin, one for trusted users, and one for untrusted user. It could look like this:
admin.example.com
trustedusers.example.com/app1 and trustedusers.example.com/app2
untrustedusers.example.com/app3 and untrustedusers.example.com/app4
You would then have 3 forwardAuth middlewares within traefik.
It is a little bit more cumbersome, but your applications are still connected to your OIDC provider using a single key, then you manage the details using keycloak and these clients.
Of course there is still the solution to have one client per application as is originally planned. This may be unnecessary, and cumbursome if you have a large number of applications (one additional container per application + additional middleware).
We have a multi-instance Saas Application:
Each of our clients is given their own instance and their own subdomain for the site.
Our application (Web app & API) is protected by Azure, currently with the ADAL javascript libraries
We also have a second API for system-level integration that needs to be protected, currently using a second 'native' azure app, but this is likely incorrect and we want to consolidate
Our application reads and writes to the Azure AD both through the AzureAD Graph API and Microsoft Graph API (including password reset calls)
We're looking at Azure AD application configuration options and want to make sure we're building the most sensible and secure Azure AD Application. Here are some of the documentation we've been looking at:
https://learn.microsoft.com/en-us/azure/active-directory/develop/active-directory-integrating-applications
https://learn.microsoft.com/en-us/azure/active-directory/develop/active-directory-v2-protocols-oauth-client-creds
https://learn.microsoft.com/en-us/azure/architecture/multitenant-identity/
https://learn.microsoft.com/en-us/azure/active-directory/develop/active-directory-v2-compare
We want the application to be multi-tenant to ease configuration, and allow availability in the Gallery; but when looking into doing so we're left with some security questions.
A. Which application version to use
1) v1. Allows access to both Graph API. And as suggested by Microsoft we should use this when we're not concerned with Microsoft Accounts.
2) v2. When looking at the MS Graph API documentation it recommends using v2. Reportedly doesn't work for AzureAD Graph API? Allows the same app to be of multiple types (Web App/API and native), which we may or may not need to protect both our web api and our system api (which we're still trying to model).
B. How to manage the reply URL when our clients have different sub-domains?
I've noted the following options:
1) On the app registry, we add the reply urls for all of our customers. This seems okay because we only need to do it once, but feels odd. Is there a limit to the number of reply urls?
2) Have one reply url, but manage an external tool to route the responses to the correct instance, leveraging the state url parameter. Microsoft seems to be suggesting that in this link: https://learn.microsoft.com/en-us/azure/architecture/multitenant-identity/authenticate I'm not sure if ADAL allows us to set the state for a return subdomain url though. Is this approach common?
3) Is it possible for each ServiceProvider instance in our client's directories to configure the reply url to their own subdomain? I feel like this would be the cleanest approach, but I don't see documentation for it. It would be nice if we could set the replyURL programmatically as well.
C. How to manage authorization to the Graph APIs (AzureAD and Microsoft Graph)
I've noted the following options:
1) Use the client credential flow, with a single application key (used for all clients). As clients subscribe they will admin consent with our app to give the application permission to their directory. Of course we'd do our best to keep that key secure. But if for some reason it was compromised this would put all of our clients at risk, not just the one instance that was compromised.
2) Same as 1, but use a certificate instead of a secret key. I understand this could be a little more secure, but I don't see how it wouldn't suffer from the same issue as 1.
3) Instead of using application permissions, use delegated permissions with an admin user. This would be good, in that it inherently prevents one instance of our app from talking to the wrong directory. However changes to the administrator may interrupt service; and I think it is best audit-wise that our application is responsible for the changes it makes. (Also, do delegated permissions allow for password resetting? I know for app permissions you need to run powershell script to upgrade the application's directory role)
4) Is there some way for the service principal to generate a unique key for it's directory on creation? can this be handed back to our app programmatically? Perhaps during admin consent?
Really good questions. I'll try to answer each to the best of my knowledge, but if someone has other ideas, feel free to comment/add your own answer.
A. Which application version to use
v2 should allow you to call Azure AD Graph API. The documentation you linked shows an example of specifying Azure AD Graph scopes:
GET https://login.microsoftonline.com/common/oauth2/v2.0/authorize?client_id=2d4d11a2-f814-46a7-890a-274a72a7309e&scope=https%3A%2F%2Fgraph.windows.net%2Fdirectory.read%20https%3A%2F2Fgraph.windows.net%2Fdirectory.write
The main decision point if you should use v2 is: Do you need to support Microsoft accounts which are not in an Azure AD? If yes, you need to use v2. Otherwise there is no problem using v1 (well, lack of dynamic permissions).
Since you are using Azure AD Graph to modify things, I'm going to guess pure Microsoft accounts will not work for you. I would recommend sticking with v1.
v2 also has some limits: https://learn.microsoft.com/en-us/azure/active-directory/develop/active-directory-v2-limitations
B. How to manage the reply URL when our clients have different sub-domains?
I could not find documentation on a limit for URLs. It could be that you can add however many you want. But I am not sure :)
If your subdomains look like this: https://customer.product.com, you can configure the reply URL as:
https://*.product.com
It will then allow any subdomain to be specified in the redirect_uri.
Though note that at the time of writing this, wildcard reply URLs are not supported in v2.
C. How to manage authorization to the Graph APIs (AzureAD and Microsoft Graph)
Using multiple keys makes no sense as they are all equal anyway :) Any of them could be used to call another tenant.
You can store the secret/certificate in an Azure Key Vault, and then use Azure AD Managed Service Identity to get it on app startup.
I would prefer using delegated permissions, but if the users of the app won't have the rights to do the things your app needs to do then that does not work.
I would just make sure it is not possible for a customer's instance to call to the APIs with another tenant id. And also make sure token caches are separated in such a way that it is not possible to get another tenant's access token (an in-memory cache on the instance would be good).
I want to implement login and logout functionality and retrive user details like username and user role using Azure Active Directory.
We are using Docker to deploy Spring cloud microservices project on Azure cloud. Could you please suggest me steps to get user details?
Do we need to secure all microservices edge points using Spring cloud OAuth2 security using JWT or just we can secure one web microservice ? Do I need any permission ,specific user roles to implement this?
You can find Azure's documentation about OAuth 2.0 support for AAD here
https://learn.microsoft.com/en-us/azure/active-directory/active-directory-protocols-oauth-code
I've got an application that's using OAuth 2.0 with a different Authentication Server, and I'm about to see if I can use AAD as the Authentication Server. But, whatever ends up being your Auth Server, the rest of the application should be the same...
The Auth Server handles the log in (typically as a Single-Sign On pattern)
The Auth Server will return a Json Web Token (at some point, depending on the Grant Type being used to retrieve it)
The JWT should be included in each subsequent request to ensure the caller has authorization
From a Spring perspective, you'll need at least a SSO Client (denoted by the #EnableOAuthSSO annotation). If everything in hosted by that process, you'll need that JWT to call subsequent methods. If you have processes hosted in other processes, it's likely you'll want them secured as well. Using the #EnableResourceServer annotation will configure Spring Security to look for the JWT, just not attempt to retrieve one if the request does not have it.
Unless the endpoint is meant to be publicly accessible, you will want to secure it. Of course, I really don't know the context of your application, so this statement is purely an uninformed opinion based on zero knowledge of what you're trying to do with your application. Take it for what it's worth.
EDIT
This has become a little more complex than I originally thought. I have been able to write some code to dynamically retrieve the public key from Microsoft in order to validate the returned JWT.
But, the main issue is the fact the Azure AD supports Open Id Connect when acting as an Identity/Authentication Server. And, at the moment, spring-security-oauth2 doesn't support Open Id Connect.
I was able to make some small changes to the spring code, but I did ask the question to the Spring group and they are actively working on adding support for Open Id Connect. They hope to have a release two months (ish?).
For the short term, the oauth2 support doesn't support Open Id Connect. Given this is the protocol used by AAD, the current version of oauth2 won't work with AAD. That said, I will be happy to wait for the official support which shouldn't be too long.
we would like to develop a new node.js based application using some SSO technology.
More applications will join then after using the same SSO infrastructure and logic.
We do not have specific requirements on the SSO itself, but it need to authenticate users
via a local DB (managing user name and passwords)
via our enterprise AD
via some external/federated SSO (I guess via SAML or so)
Also if it would support XACML it would be great.
I believe one of the most complete solutions on the market is the WSO2 Identity Server... but we would be open for others too.
The main question though is simply:
Is it possible to have such a solution in node.js?
Or do we need to shield node.js behind some (Apache) server to get SSO?
What would be the best approach?
Any inputs would be appreciated.
I've used azure active directory in my node.js projects for authentication, this might work as you are using active directory. Here is a sample.
I know there are a lot of questions about Azure ACS, but I want to ask a more general one:
Should I use ACS, or it's not worth the effort? :)
What I want is a secure WebService in Azure that will be called from 2 places: a mobile app and another service inside Azure. Users will never access this webService directly.
Thanks
Update:
I don't care much about the identity of the user that is behind my mobile app.
I think it depends on the specific scenario, you say that users will not access the service dicrecly, but presumably it is the user who will use the mobile and/or web app.
Thinking of authentication and authorisation - if all you need to do is identify that you're coming from your own appilcation, than there are defintiely leaner approaches. simple certificate based solution would do, or even username/password based solution.
If, however, you wish to use the identity of user beheind the app to drive the authentication and authorisation for the service, than you do need to worry about the user's identity, and of course you can manage it yourself, but this is where the ACS comes very handy in that it lets you leverage one or more existing identity providers, which makes it easier for you and the user.
It's probably not worth it.
ACS is great for managing user identity on your behalf: in other words, for allowing your users to make identity claims.
If your Web service needs to know about your users' identities then it's definitely worth the (small) effort to implement, as it takes care of much of the work for you.
If your Web service doesn't know about user identity, and there's no external endpoint defined for the service -- then, yes, I'd not bother with ACS either.