I have a MVC web application that needs to be authenticated against Okta (the users will be stored in Okta). I have some third party applications to which my customers will navigate through their links in my website. The customers, once they are authenticated while coming to my page should not have to be authenticated again when they navigate to these third party links.
I also have have some third party web sites consuming my external exposed web services (MVC Web APIs). These third party applications are also expected to authenticate themselves through Okta.
How can I implement these two scenarios? I know how to implement the customer authentication by Okta using their APIs, but the part not clear is how to enable the seamless navigation between the third party websites.
Related
I have a web application written in MVC 5 Asp.Net 4.7, C# on Azure App Service. I want to integrate it with a 3rd party web application, via its API, using OAUTH2 whereby the server application punches out to it, causing its Identity Server to acquire user credentials and then to finally issue a Refresh and Access token so my application can make calls on it API.
Now to my question.... As I understand it the recommended OAUTH code flow for this is "Authorisation Code Flow", however the 3rd party wishes me to use "Hybrid Flow" as they have been advised this is more secure. Is this correct? I emphasise this is a web server to web server interchange, apart from the redirection by the 3rd party identiry server for user credentials.
Thank you in advance.
I am building an OAuth2 API for my program. But I don't know how the flow works for using the same API on the main website for the app? Would I just use the normal authentication route? I think it would seem odd to see that the trusted name app is wanting access to information, when its not a third party.
I am developing an asp.net MVC web application that will be deployed in the cloud and should support the following authentication scenarios:
Transparent authentication for domain users on an intranet. These users should be able to access the application without signing in.
Forms login for arbitrary non-domain users on the internet. These users should be presented with a login page using Forms authentication, and membership is managed internally by the application.
Forms login for domain users on the public internet. They should be able to use the same login form as non-domain users, but sign in with their domain credentials instead.
Active Directory Federation Services (ADFS) with passive authentication can cover cases #1 and #3. Since it redirects to the federation provider's login page, it doesn't cover the #2 case. I understand active authentication by my application could possibly support all three cases, however there is not much documentation around on how this would be implemented.
Ideally there should be a way for my application to authenticate a domain username and password with the ADFS federation provider.
Does anyone know whether this is possible, and if so, how?
The standard pattern for this is ADFS with a split DNS - IWA for intranet and Forms for internet.
However, ADFS can ONLY authenticate against AD so option 2 can't be achieved.
I would suggest using IdentityServer for option 2 - you may have to customise it depending on your "flavour" of membership - and then federate ADFS and IdentityServer.
IdentityServer is free / open source.
To expand on nzpcmad's answer, you can set up Claims Provider trusts other than Active Directory in the ADFS Management console under Trust Relationships > Claims Provider Trusts, they effectively chain ADFS with custom STS services.
The entries you add will be added to the Home Realm discovery page within the ADFS web site, such that authenticating users will be presented with a drop-down list to essentially choose the Claims Provider they wish to be authenticated against.
Automatic sign-in will still work for internal users who choose your Active Directory (ADFS provider), whilst members of other Providers will be redirected to their chosen Claims Provider's web site, which will typically present a Forms login page and authenticate against a back-end membership database, all external users (who are not able to present an NTLM or Kerberos token will be required to enter their details - for AD users this will mean they have to enter their domain\user string (or user#domain) and internal password.
Of course, you have to create these providers yourself, in the old WIF days this meant using the fairly clunky Custom STS template, however you can now streamline the procedure with a simple OWIN-based MVC5 site. Alternatively, as nzpcmad suggests, you could look at using IdentityServer.
I'm looking for some guidance on what people think are the best set of technologies to use. We are looking to create a web portal to allow customers to register/login with standard credentials or their social accounts (Google, Twitter etc).
Once they are registered and logged in to the portal they can access our different web apps which will know who they are and what permissions they have based on a token. We will also need to secure a set of web APIs using some sort of OAuth mechanism, so the user would possibly create an account on the web app and then create an application which would give them the keys they need to access the API from their own app.
We have a basic portal app using MVC 4 and DotNetOpenAuth which allows a user to create an account and login with either a username and password or their Google, Facebook account etc.
The APIs would be MVC 4 Web APIs
Ideally the whole set up needs to be as simple as possible, I've briefly looked into using Windows Azure Access Control (ACS) as a way to cut out some of the heavy lifting but its hard to tell where exactly it all fits together.
Currently we run an ADFS 2.0 server and WIF to allow web login to our apps but it doesn't seem like it would be an ideal choice when integrating the social login and for securing the web APIs
I guess it could be two quite seperate parts, once they are logged into the portal, how would we go about providing some sort of claims token to the other apps they then access to understand who the user is and what they are allowed to do. And maybe the web API authentication/authorisation is its own entity?
Thanks for your time
We ended up using the built in MVC 4 login system and also added JWT token support, when a user is logged in a JWT token containing their claims is stored as a cookie. This is then automatically passed around our sites on the same domain by the browser, when the web API is called from javascript it checks for the token in the headers sent by the browser and either validates it and returns the correct data or returns an unauthorised response.
It doesn't cover all the bases, we can't give trusted third parties access to our web services yet
How would I go about handling authentication in a RESTful way that will work with desktop/mobile apps? For eg. I know how to build authentication in my apps by using FormsAuthentication, which relies on cookies, which I assume only works with browsers.
Do I still use FormsAuthentication? My login method takes passwords and usernames, and I plan to use other 3rd party logins such as google, twitter and facebook.
So for the password and username, the client sends that to the server, how do I set it up so an android or windows phone 7 app can authenticate with it.
I'm also exposing some actions with the [Authorize] attribute.
Dominik Bayer did a great talk at NDC 2011 about securing rest services. He discusses pros and cons of multiple ways. A good point to start from...
You have to seperate Authentication and Authorization.
If you go with multiple Login-Provider (google, facebook, twitter) then Oauth would be the choice...
But more details here:
Securing REST-Services and Web-APIs:
http://ndc2011.macsimum.no/SAL1/Torsdag/1740-1840.wmv