I have a claims aware MVC website setup using the Thinktecture Identity Server. I now have a requirement to allow a 3rd party to access certain parts of the website.
Is it possible to programmatically authenticate with the Identity Server and post this to the website so that the user at the 3rd party is not required to manually go through the normal login process?
I have previously used the identity server to obtain a SAML token for the purpose of making WCF calls, I was wondering if it would be possible to re-use some of this approach?
The complications arise from the fact that the 3rd party are using a desktop based Java app with some browser component built in for accessing the MVC website. Users are already authenticated with the desktop app so we don't want them entering credentials again to view these web pages.
Hmm, tough one to solve in a secure fashion. Basically I don't trust desktop apps ;-)
You might be looking for some sort of federation. Basically it is about letting your Identity Server trust the 3rd party (by means of signature). Your Identity Server would then use a SAML token from 3rd party as login information and generate a new SAML token (signed by you) to forward to the the MVC web application. I think Dominick has a video or two about it, but not sure it meets your requirements. Take a look at https://github.com/thinktecture/Thinktecture.IdentityServer.v2/wiki
The Java desktop app probably cannot create a signed SAML token, so you could consider using "something else". Preferably something signed from where they logged in the first time.
You should avoid having your web app trust anyone but your own Identity Server / Identity Provider.
Hope this helps? Happy to help where I can :-)
Related
I am trying to capture a SAML token that my ADFS login gives me. I need to capture the SAML by browsing to the ADFS login page, Let the user login and then when login is successful return the SAML back to the application. The application tehn calls a WCF service passing the SAML token in the header. I have a Url like :
https://adfs.mydomain/adfs/ls/IdpInitiatedSignOn.aspx?RedirectToIdentityProvider=http://adfs.mydomain/adfs/services/trust&loginToRP=https://bcjbsj.com/client-api/api/saml
I need to get this working wither in a windows application or console application. If this is not possible I can create a ASP .NET application also for testing. I have gone though many links but not able to find anything that helps.
I may be missing something here. Quite new to authentication. Any help or pointers would be helpful.
This is easily accomplished using a technique (occasionally) called JavascriptNotify. The basic idea is to display a WebBrowser control that you extend via javascript to allow callbacks to your app code once authentication is complete. You need to provide either centrally or packaged with your app an SP-STS that presents the home realm discovery page and the final jsnotify page. The rest of the UI is handled by the trusted STS's. You can optionally use Azure ACS to fill this role.
See Authenticating Users from Passive IPs in Rich Client Apps – via ACS or Access Control Service: Transitioning between Active and Passive Scenarios for what the call sequence looks like.
To understand how to add the required window.external methods, see Invoke C# code from JavaScript in a Document in a WebBrowser. Thinktecture has an example client in WPF implementing javascriptnotify with JST.
As #Thuan mentions, the other option would be to abandon WS-Federation passive authentication in favor of WS-Trust active authentication. The downside in this approach is that it is far less flexible, and you must implement the client-side UI yourself. Having written apps that implemented both WS-Trust and WS-Fed RP's, I highly recommend WS-Fed passive authentication even for desktop apps.
That endpoint is used for passive login (aka via browser) scenarios. For Windows application or console, WS-Trust is a more appropriate approach. In short, your application uses WS-Trust protocol to call ADFS to get a token that can be used to access a WCF service. Such a WCF service is called claim-based service or claim-aware service. This question has a bunch of good links: WCF, Claims, ADFS 3.0
I have created a Web API application, an MVC application, and a mobile application.
The Web API should be decoupled from the other two applications as much as possible. I'm using the Password Grant flow here: clients using the Web API needs to send a POST to /Token with username and password. The returned access token is then used for further calls to the API using standard Authorization: Bearer <access_token>.
The MVC application is only accessible for a select few users, and it has its own database which contains the information and roles of these users. Some parts of the MVC application should be restricted to only one or two users (for example), while other parts should be accessible for all registered users. This can be done by using Authorize attributes on the specific controllers within the MVC application - all good. Furthermore, the MVC application should be able to interact with the Web API.
Secondly, I want to have a mobile application to be able to interact with the Web API. A key point here is that I won't require users to register in the app. So essentially, (how it's in my head right now) the only thing the API would see is "this token belongs to the "AndroidApp" user and has password X - sure thing, you're known to me, I'll grant you access". This seems to me a bit 'insecure', meaning that all users of the mobile app will share the same auth credentials.
Questions:
User A is one of the users who are allowed to access the MVC application - I want him to be recognized by both the MVC app, and thereafter the Web API. Is there an easy way to synchronize data between two databases, or should I just register him in both databases (one for MVC, one for API)? There is probably a better third option I haven't thought about.
User B is a user of the mobile application, and he should not be able to access the MVC application. How can this be ensured? Obviously, the MVC user database won't have any info about mobile app users. I'm just wondering about the security aspect of just having one single pair of auth credentials embedded in the app - doesn't sound good to me.
I stumbled upon this question, which basically is the same as mine. But I don't really see the need for Authorization Code Grant flow for the web app (MVC application in my case) as the accepted answer suggests.
I hope my questions make sense, otherwise please let me know :)
My answer doesn't directly answer your question but rather offers an alternative.
In the past when developing similar solutions I've used a specialist third party identity service Auth0.
With Auth0 you can have different application keys, profiles and also create rules (webhooks) which are executed as part of the authentication pipeline. They offer a range of social login as well as AD integration. They offer free and paid pricing.
I am not affiliated with Auth0 in any way, but will use their service as the starting point for any projects going forward - Yes it's a really impressive service!
I currently have two web applications, one of which is a web api, which both have it's own implementation of ASP.NET Identity for authenticating users (first one is cookie and second one is bearer tokens).
I need, in the near future, to add a third web site to the family and was thinking to move the authentication logic in a standalone web application which could serve all the orhers.
For example: instead of authenticating to www.mysite.com and/or api.mysite.com, I would like that both the applications could authenticate against a new website, like e.g. login.mysite.com, as microsoft does.
How can I achieve something like this? Does somebody has any direction to start with?
What you need is an Identity Server which will authenticate the requests and give you back an access token. You can then use the access token to make subsequent requests to APIs and websites etc. As long as the access token is valid you will be able to make requests. There is great .net based open source solution available for Identity Server. Have a look at Thinktecture. You can download the source and demo projects to try yourself.
I want to authenticate a user using a third-party system when they hit a Controller or ApiController with the [Authorize] attribute, but I really don't want to have to create associated users and logins that OWIN requires in order to create the cookie that keeps the user session authorized, because our third-party system is already tracking that.
Normally, you'd map OWIN logins to external logins, but our system, as-is, is so tightly integrated with this third-party system that there are a bunch of reasons (that I won't go into) that we don't want to do that.
Is there a simple way to use ASP.NET MVC5 out of the box that allows you to authenticate to another system, and then mark the session as Authenticated without having to find/register them in OWIN?
Sorry if this isn't a lot to go on. I've not seen any way to go about this without perhaps implementing our own IAuthenticationManager, but I'm not even sure where I'd start to do that.
Thanks for any help you can offer.
I believe OAuth is the only ASP.NET SSO support you get out of the box. It would help if you elaborate on the nature of the third party authentication system, since you'll need to integrate with it in order to provide the SSO experience.
Here are a couple of blog posts explaining how to create custom OWIN authentication middleware, which seems to be what you'll need to do to set ASP.NET Identity based on some information from an external system (header, cookie, token, etc). I used the second approach to integrate with CA SiteMinder (commercial web authentication product).
Owin Auth 1
Owin Auth 2
I ended up solving this by creating my own implementation of IUserStore and its associated classes that wraps the third-party system.
I have a SaaS web application that caters to multiple education institutions. All clients are hosted in the same application/database. The application is currently written in C# for ASP.Net 4 Web Forms.
Currently my application uses a local/native database for user authentication/authorization.
Our clients are asking us to support single-sign-on where the client is the authentication provider and my application the consumer.
The problem is that the clients are asking for SSO via different protocols/mechanisms like Shibboleth and OpenID Connect. This means I need-to/should create a solution that works with all of these or that is at least extensible.
I came across Thinktecture's IdentityServer, which I think can abstract the various SSO mechanisms used by my clients and return to my app a claims based identity token that my app understands.
I'm struggling a lot with this concept though. Does this mean that my app redirects all authentication requests to the IdentityServer, lets IdentityServer handle the back and forth of say OpenID Connect, and then receives a token back from IdentityServer with the information I need about the user? How does the identity server know the realm of the user (i.e. so it knows which client auth provider to send the user to)? Does the IdentityServer need to validate the existence of the user in my app's local/native database? Can the IdentityServer handle both SSO and local logins?
Is a separate identity server the way to go? It seems like it would be, allowing my app to integrate with one point (the identity server). But, there's not a lot of documentation out there on Thinktecture's IdentityServer other than how to configure it. ADFS may provide a similar solution, but most examples out there speak to ADFS and Azure.
Lastly, I'm assuming that I'll still maintain local/native authorization data about each user as the 3rd party authentication provider can't possibly know the specific authorization needs of my application.
Any thoughts or suggestions out there?
Does this mean that my app redirects all authentication requests to the IdentityServer, lets IdentityServer handle the back and forth of say OpenID Connect, and then receives a token back from IdentityServer with the information I need about the user?
Basically YES. But it depends on how you set it up. Your page could call Authentication provider of the client if you have only one client or one authentication provider. Or you could set up your local IdentityServer (more extensible IMHO) and configure authentication provider of your client as another IdP (identity provider).
How does the identity server know the realm of the user (i.e. so it knows which client auth provider to send the user to)?
If you go with the second option then your app will redirect to IdentityServer and based on home realm it will be automatically redirected to IdP. If no home realm is specified by your application then IdentityServer will show all configured IdPs and user chooses what IdP to authenticate at.
Does the IdentityServer need to validate the existence of the user in my app's local/native database?
It depends on you. If you wish to verify the existence of the user in your local database then you may do so by extending IdentityServer.
Can the IdentityServer handle both SSO and local logins?
Yes, it can.
Is a separate identity server the way to go? It seems like it would be, allowing my app to integrate with one point (the identity server).
You can always use IdentityServer and integrate it in your local application. Or you can use Shiboleth as your local authentication provider. Both are implementing standards like WS-Federation, WS-Trust or OpenId and both are open source so you can extend/modify it to your liking.
But, there's not a lot of documentation out there on Thinktecture's IdentityServer other than how to configure it.
I can't really say how much documentation is there. But if you wish, NDC Oslo 2014 will feature 2 days of Pre-Conference Workshops where Dominick Baier and Brock Allen (authors of IdentityServer) will teach you everything you want to know.