I have a web application which runs on one server, but multiple domains (like ab.c, a-b.c, ab.d, a-b.d etc.) are pointed to this application. I would like to use other systems' (e.g. Google, Facebook, Microsoft) authentication. Google and Facebook are working fine, but it looks like Microsoft Live allows only one domain per application. Is that correct? If yes how to handle this? Does it exactly means I have to create separate application on MS developers site and I have to choose different Client ID for authentication based on user's referrer?
Related
I work for a company where we give customer (hundreds/thousands of users) access to 2 sites. One owned by a 3rd party SaaS and one owned by us.
Customers spend alot of time registering for both sites and we also spend alot of time removing accounts when customers no longer need access.
I would like users to register for Site A. After successful authentication; a user can click on a link within the site to access Site B but without the user entering credentials.
I want Site A identity to be used to access site B and its resources. I do not need site B resources to be presented on Site A site, but simply allow users to access site B if already authenticated to site A.
Users may have different roles on site B.
What is my best option? Oauth2 sounds like a good option. But will it satisfy my requirement above?
Who will manage the authorisation server? I presume Site B?
Thank you.
Two main options:
OLD TECH WITH COOKIES
Perhaps the cheapest option is to use hosting domains and have 2 apps like this:
mail.google.com
drive.google.com
Use a cookie issued to the parent domain, google.com
Cookie identifies user, to provide a user id
Rights are looked up in each app from the user id
OAUTH2 AND OPENID CONNECT
This is the option for modern apps and they are usually used together, due to being web, mobile and API friendly.
It is a big job though, including user migration, and usually involves giving users a new password. So it needs to be something your company are prepared to invest in.
The Authorization Server (AS) becomes a shared central resource and it is common to use a Cloud Provider to ensure high availability.
RELATED RESOURCES OF MINE
Initial Code Sample with Cloud AS
User Migration Blog Post
I recently switched to a new company where my manager wants me to develop entirely new cloud based project in MVC. I have never worked on a project from the start and I think this is a good opportunity for me to lead.
However, I think the requirements of the clients are bit confusing.
Here is what he wants:
Client should be able to access the cloud hosted application from his network with single sign on. He wants to use his active directory for that.
There are different users in active directory, they will have different roles (I think we can handle this on database side. Create different roles and assign roles to users).
Client has to add vendor info in the application. But for this, system should send an email to vendor with the url of the cloud application. He wants user to login to the application using 2 Factor Authentication. So, send dummy password with url, and send OTP to his mobile number. Just like registering to any system.
Now my questions are:
Is it possible to have 2 different types of login mechanisms in the same application? SSO for client and 2FA for outside vendors?
If yes, could you please guide me in the right direction?
what things I need? Which framework, design pattern should I prefer?
How do I proceed ?
I have an ASP.NET application hosted as Azure App Service. This application is configured with Microsoft Authentication. But the problem is anyone with hotmail/live account will be able to access the application.
I wanted to restrict the access to my Application Pages to SPECIFIC hotmail/live users only.
What changes I have to do on Azure Portal?
What changes I have to do in my application?
Thanks,
Paraclete
Applications typically have two "gates" of security - authentication and authorisation.
The simplest way would be to set up a list in a store (e.g. SQL DB - or hard code for testing) of authorised users. Let the Microsoft Authentication handle authentication and then use your list for authorisation. Redirect to HTTP Status code 403 forbidden if a user is not in the list of approved users.
You could make this a bit more fancy by implementing groups/roles, which is more elegant and manageable. Look in to the ASP.NET Role provider for built in functionality to expedite development. That said, some people find this build in approach cumbersome and roll their own simple provider and add it in to the page life cycle or the master page to share the functionality across all pages.
OAuth does not support the concept of a 'Universal Logout'. Logging out of one application does not log you out of another, as that would not be the desired behavior.
For example, if a Facebook user were to log out of Facebook, it should not log them out of Spotify (if they were using Facebook OAuth).
I have been hired to create a service that acts as a sub-application to transparently embed itself in the workflow of an older monolithic web application. For example, there is a link to the sub-application from the monolith, and clicking that link transparently moves you into the sub application. The sub-application also links back to the monolith, which transparently leads back. The user is able to weave back and forth between the monolith and the sub-application.
The sub-application currently uses OAuth 2.0 to authenticate through the monolith. From the user's perspective, this is mostly a transparent exchange.
To the user, the two application workflows should weave together as one. Given this, the concept of a 'Universal Logout' is desirable. What appears to be a single application to the user should not have some of the pages logged out and other pages logged in.
I currently have a 'Universal Logout' implemented, but I have a feeling that since this is not a part of OAuth, maybe it means this problem should be tackled in a different way.
Given this scenario, is there an alternative to implementing 'Universal Logout' in OAuth? Should OAuth even be used? If not, what should be done? How could this be better architectured?
OAuth 2.0 itself is not a protocol that logs on users to applications (http://oauth.net/articles/authentication/); some (like Facebook) have built a custom extension of OAuth 2.0 to do that; those providers would have to start supporting a custom Single Logout mechanism as well in order to address the problem you mentioned.
There is however a standardized extension of OAuth 2.0 that logs on users to applications called OpenID Connect (http://openid.net/specs/openid-connect-core-1_0.html). That has an extension called Session Management (https://openid.net/specs/openid-connect-session-1_0.html) that allows for the functionality that you describe in a standardized way.
Our customer is using LDAP and 3 web application. The problem is the user is constantly forced to log on to each different web application.
He shall be able to use Windows authentication / LDAP together with single sign-on in order to be able to use all 3 Web apps without redirect to each login page.
So far, I have found this solution:
https://msdn.microsoft.com/en-us/library/ms972971.aspx
in this case "This Web site verifies (Step 2) the user against their Windows credentials (through Active Directory)." I don't understand how to check users password.
In this example is used only userid. Does it mean, that I'm only able to get users ID and check if a user with the same ID exists in LDAP ?
I would like to know, if there's an another and better way how to implement described functionality.
Please help