Assume I have two web applications and single STS service:
1. Administration portal where I can grant privileges to users.
2. Sales portal where users can do things based on those privileges.
Now assume I have STS that provides security tokens with 8 hours expiration to Sales portal. Token contains claims that carry information about privileges for user, among other things.
Now imagine a scenario where on the Administration portal privilege is removed for the user and change has been saved to the database. Since user is already logged in to Sales portal with security token that has not yet expired, Sales portal will not be aware that privilege has been removed.
Question is - how to handle this scenario. To me the only solution that I can see here is complete removal of STS, but I'm looking for a smarter way to handle this.
Is there a better approach to this out-of-sync issue?
Removing the STS is a little bit drastic :-). You have it for a reason (SSO, federation, etc). You have a few options: decrease the expiration time of the token to a reasonable value for the volatility of your changes (8 hours might be excessive), or move the sensitive authorization information (e.g. privileges) to the app so it is checked each time.
You can do "claims enrichment" at the app level (through a custom AuhtenticationManager in WIF) and still use claims model from your app code.
Technically there's no synching between the app and the STS. The Token is a snapshot of user attributes at the time of issuance and valid until it expires.
Related
I have a user permission system in place where i have a set of permissions within the database, for example
id
Permission
1
POST:CreateBooking
2
GET:AllBookings
And i have another table (junction table) where i put dependent permissions such as
if i want to create a Booking, i need to fetch Package details and so POST:CreateBooking requires the user to also have GET:AllPackages permission.
There's a template system in place as well, where the users can group multiple permissions together and once that template is assigned to any employee, that employee will get THAT set of permissions and it's dependent permissions.
What my nodejs system does is that when user logs in, it fetches all permissions from DB and puts it in a redis set from where on each request, the permission is checked against user id.
Is there any tool from where i can do exactly this but in an intuitive and better way?
I tried keycloak but i don't know how to cover my needs mentioned above.
Thank you
if I'm understanding correctly and trying to generify your scenario, you have a classical situation where:
You have groups which can have multiple permissions assigned;
groups can be created dinamically;
each permission correspond to a specific functionality.
So, implementing the OIDC (Open Id Connect) protocol might fit you needs. As you suggested youself you might be interested in a OpenID provider (do not reinvent the wheel) keycloak is good, you can give a look also to Vault Hashicorp.
So assuming that your backend have an already existing framework to handle security and permissions (eg. Spring Security) you can produce JWT token with the OpenId provider and check throught PreAuthorize claims (permissions) inside the token.
At the end your security layer it's just an annotation you need to insert before your method controller or before you class controller.
Behind the scenes, instead, this is what will happen:
Your user connect to your app;
User insert username and password -> the Open Id provider gives you a JWT
Your Front End app everytime it make a REST req will send also the JWT
The back end controller method called it's under authorization
Given the public keys of the OpenId provider, the validity of the token it's enstablished
If the specific permission claim it's found inside the token, the request can be elaborated else a 403 Forbidden it's returned.
OIDC - as the conceptual model/backdrop to any tool of choice, is certainly a popular/good choice, but as long as you're willing to deal with an element of complexity - the understanding required to implement an OIDC arrangement (- think of it as a possible investment - effort up front with hopefully the rewards tricking-in over time); e.g. OIDC is an ideal choice for supporting SSO (Single Sign On), especially when it comes to supporting/allowing for authentication/login via providers such as Facebook, LinkedIn & Google, etc (- as well as more Corporate OPs (OIDC Providers) including AAD/Azure AD).
Try to first step-back, and consider the possible bigger/future picture, before selecting a tool based upon only your starting/current requirements.
Edit
It is not a duplicate: The other question is about Sign Up, this is about Sign In. What's more: That question is about email verification, this question about quotas/throttling. Those are different elements of a middleware policy. Although the consequences could be similar, the issue itself and also the solution is different. Please remove the duplicate flag
In case of a malicious user scripts her/his Sign In/Sign Out against your application/web site, which uses AD B2C it can cause millions of Sign In within a reasonable short term.
Because of you will be billed based on the count of Sign Ins (free for < 50 000, then pay) this will not be a happy hour.
Question
Is there any way to prevent the scenario above? (limiting payment is not an option, this case after the attack your site will be unable to serve Sign In user flow)
Azure AD B2C has mitigation techniques against malicious attacks like you the ones you described, and B2C will automatically lock out the user for a certain period of time.
More info: https://learn.microsoft.com/en-us/azure/active-directory-b2c/active-directory-b2c-reference-threat-management#password-attacks
At the moment, with smart lockouts(as mentioned in the link above) admins cannot control the number of attempts. But if you want to be able to configure that and maybe, even take an action (like MFA) you can do that with custom policies: https://learn.microsoft.com/en-us/azure/active-directory-b2c/active-directory-b2c-get-started-custom
Azure AD B2C community on GitHub has a sample to lock out the user after 6 unsuccessful sign-ins.
https://github.com/azure-ad-b2c/samples/tree/master/policies/lockout
We are building a enterprise product, and expect a lot of customers, to not have active directory of their own.
We plan to use AAD as our IAM provider.
We plan to create a master AAD for the product, and then invite users of each customer (tenant) as external users to the master AAD, using their business email id. Each set of users for a given customer, will be added to an external group for manageability.
Would this be the right approach, for supporting multi-tenanted IAM for a product hosted in Azure?
It's a pretty hard question. AAD's multi-tenancy basically requires the org to have an AAD to have proper separation etc.
But in the case of an org not having an AAD, this is one option.
One crucial thing you must not forget with this path is to turn on the option in the AAD tenant to restrict Guest user permissions. This makes it so that the invited users can't just go to portal.azure.com and get a full list of all users in the tenant. At least usually this is a desired thing when multiple clients are in the same tenant.
Other options could be:
Setting up an AAD tenant for each customer
Good separation for customers
There might be a limit how many you can create
I'm not aware of an API you could use for this (but hey Selenium works :D)
Set up your own identity provider with e.g. IdentityServer
Maximum customizability
Lot of work for you to develop and maintain
Everything would of course be easier if they just had an AAD :)
It would depend on some details of the approach you want to follow. If you are expecting for them to use their business email, then you may consider having Single Sign-On (many organizations expect not needing to duplicate accounts and you may want to delegate your customers the hassle of resetting passwords).
Also, you need to determine what kind of isolation need(do you want to have a single set of users or have a clear separation by tenant?) and the budget (AAD cost is measured on a per-user basis) you have for this? Azure AD B2C could be also an option, or as #juunas mentioned, implementing your own solution with something like IdentityServer.
I'm building a Windows 8.1 store app and need to incorporate authentication. This is an enterprise app used in house. We load the app onto a tablet and a team may check that tablet out for weeks at a time, go out to the field to collect data and then we put in on a shelf until another team needs to use it. Now different teams may work for difference clients so when we authenticate users not only do they get access to the app but we also check what groups they are in to determine what clients they can work on or what previous records they can search for.
I've followed various ADAL tutorials and am able to setup everything in Azure and in my app I am able to authenticate a user successfully and get their groups. This relies on ADAL handling the username/password. What happens when the app shuts down and the user in a place where there is no internet (or even a reliable cell connection)? Specifically how can I have the user type a username/password to re-authenticate and get the same groups they were in when they can't access Azure services?
It appears they isn't available as the guidance always points to that is a risky proposition to have the app handle username/passwords. I understand that stance and can appreciate the caution behind it. However, in all of the ADAL documentation that I find that says this, none of them tell me how to handle an offline authentication scenario.
I have found links such as ADAL v3: How to authenticate using UserPasswordCredential? that tell me how to bypass the ADAL login page. I may have to move to that route and handle all of the username/passwords securely within the app, but first I would like to reach out and see how others tackle this scenario. Is it really as simple as avoiding best practices and just handle the username/password within the app?
If anyone has some guidance, ADAL (or other oauth providers) documentation, or other articles/advice I can follow up on to help achieve offline authentication I would greatly appreciate it!
Additional Information:
My scenario that I'm trying to cover is what happens when I have 1 device, 1 app, and many different users? These users will be in different groups that will determine how data fields get populated (filter data in combo boxes) and what previously submitted forms they can query for. All users would need to login when online to cache their information (say on Day 0) before they can ever use the app. On Day 1 user 1 uses the app and doesn't log out. I would expect the app to have a timeout timer to log that user out after 2 hours of no activity. On Day 2, user 2 just grabs the device off the shelf and takes it out into the field. He has no internet and needs to log in to determine who they are and what group they are in. I would expect since he has logged in once and verified his credentials already that we can enable this sort of scenario.
What I'm looking for is guidance if ADAL as a library can handle this or is it truly up to me the app developer to handle this sort of scenario. As I see it currently I need to store all user credentials, but at the same time it seems like everyone advises against that. I feel like I'm in a situation where I need to create a custom login screen and store the user data, SECURELY of course, even though its not recommended. It seems like all articles on how to use ADAL are written from a consumer app standpoint (or a BYOD) and don't take into account how a mobile app would be written for the enterprise.
That depends on your app design, if the first time(app online) , user login and app store all groups ,user information .After that user doesn't need to use token to get related information again(send request to server to acquire groups/user info). If app is offline , user doesn't need to re-authenticate(app controls the user session) , just get group/user information from cache . When using resource owner flow , you still need to send authenticate request to Azure AD server which need internet.
We want to implement SSO functionality in our organization, but we're not really sure what our options are, and what the benefits / disadvantages for the different solutions might be.
-We have multiple old ASP(Active Server Pages) sites which should use SSO
-We have multiple ASP.net web-Applications which should use SSO
-We want Sharepoint to use the SSO
-CRM (Biztalk?) integration (Additional information about the user, such as Address, company, etc )
Since we're primarly .net, c#, Microsoft oriented, my first idea was to use Active Directory.
I've also noticed that there is something called ADAM (Active Directory Application Mode), and ADFS (Active Directory Federation Services), but I can't really say I understand when/where these should be used.
Here is a brief overview of the different web-applications
-"My Personal Page" : User log's into an application where they can modify their personal information along with their company-information and their employees. (Asp.Net)
-E-learning application (ASP)
-CMS system for web-publishing (ASP.Net)
-Sharepoint sites
I haven't really been able to find any articles that can tell me "AD is a great choice! , you can use it everywhere", so If anyone has got any experience /feedback to give me on this, it would be really helpful.
Also: How should rights/roles be managed ? Should all access/rights/roles for each application be stored in AD, or should this be stored in the applications themselves.
IE : AD stores the roles:
"Cms" <-allowed to login to the cms system
"Cms.Article.AddAllowed" <-allowed to add article
"Cms.Article.DeleteAllowed" <-allowed to delete article
Or should this information be split up, so that AD holds information about which applications the user is allowed to log into, while the application itself holds information about what the user is allowed to do within the application when logged in
AD rights:
"Cms" <-Allowed to login to the cms system
Cms rights:
"Article.AddAllowed" <-allowed to add article
"Article.DeleteAllowed" <-allowed to delete article
So, when the user logs in, they are first authenticated against AD, and if that goes ok, the rights for the Cms application is fetched from a rights-table in the cms system ?
What are my options ? What other solutions other than AD do I have ?
Thank you for any feedback, its much appreciated !
We have done something similar in my organization. Here is the overall flow:
User requests web page
User is redirect to login screen along with SAML request
User authenticates against Active Directory
User is passed back to request web page with SAML response
User group/rights information is retrieved from database
If user requests page from another website same process occurs however if the user still has a session or selected the "remember me" feature then user does not have authenticate and gets logged in directly.
We use Sharepoint, but have not setup SSO yet. I believe Sharepoint gets the rights of the user from its own backend database/system. We also have a homegrown system to update user's groups/rights. I know Sharepoint can use web services so you could possible update Sharepoint when using a centralized user management system (of course you'd have to build that). The main thing is finding out where Sharepoint gets its information about the user and how you can tie your existing system to it...
I wouldn't rely on Active Directory to store group/rights information. It a pain to deal with compared to a database and is not flexible. It's fine for authentication and password management you just have to tie the user on Active Directory to your database system.
As far as I know, Active Directory is only practical for users within your domain. You would need an administrator to manage all those users and to add new users.
I've been working on a project myself where I wanted users to sign in, just to know their identity. I did not even care about their access rights but just wanted an identity on every visitor, something more reliable than an IP address, cookie, session key or whatever else. So I first asked my administrators if I could use Active Directory for this project. Sure, I could. But the webhost wasn't connected to our company domain so I would end up with only one user. Yeah, my administrator is a bit sarcastic sometimes.
So I started to explore SSO options. OpenID like this site is a good option and you could even implement your own OpenID server and require all visitors to sign on there first. It's a very powerful technique and you have less worries about managing users in your project. (Because the OpenID provider takes care of this.)
However, I ended up using CardSpace instead. :-) With CardSpace, every user can create their own user-token and store it on their own system. To log on, the website just asks for the card and the user just clicks on it. Those cards can be migrated to other systems but tend to be tied to a single computer and user, most of the time. (Although users can share a card!)
Rights and Roles are a different matter than Authentication. People always think they're connected while in reality, these are two different things. First, use OpenID or CardSpace or another authentication technique to verify the identity of the user. It doesn't matter how they're identified, you just need an identifier.
Next, you need rights and roles. Roles are basically just user-groups and you can connect an identity to a group. Or to multiple groups. And rights would be linked to roles, not users. But how you're going to divide these roles just depends on the applications. Just remember that someone who is an administrator in your version control system should not be an administrator in your customer database. Roles tend to be application-defined, thus every application could manage their own rights and roles and just needs a way to link these to an identity.
I myself just needed identities so I knew whom to blame when something ended up messed up. Then again, when there's only 5 users, things tend to become quite simple.