I'm almost driving crazy looking for the right way to implement appropriate authentication functionality for my OWIN/Katana project using SignalR.
I already read about writing an own OAuth2.0 Service, I heard about using cookie authentication, and using SignalR's [Authorize] attribute. Yet, I am not quite sure about whether any of these approaches meet my requirements.
I have the following scenario:
I've got a host application that performs a WebApp.Start() for let's say TWO owin hosts.
Each owin host has various middlewares.
What I want to do: At the beginning of each OWIN pipeline I want to add an OWIN middleware that presents a login-page and allows the user to authenticate. If the user has been successfully authenticated, he is able to reach any other middlware in the pipeline. If the user browses to a further pipeline before authenticating, he should be redirected to the login page.
The problem: I found plenty of articles describing how to write an OAuth 2.0 server and so on. What I did NOT found is a step-by-step tutorial showing how to authenticate using JavaScript and after that, share and use the authentication data in each middleware that has to check if the user is authenticated.
Does anyone have a good tutorial of how to achieve something like this?
Or, is it even possible to share the authentication data between multiple OWIN IAppBuilder instances. (Each middleware is a separated DLL, in my case.)
Please don't blame me for not reading any documentation or something, I really did already spend a looot of time investigating in how to approach something like this. IMHO there is no really good article describing how to achieve something like that.
Or, at least, can anyone explain to me how to work something out?
Thanks in advance!
Ronald
Project structure: https://pl.vc/2y86u
I have a project OWIN.Framework that allows you to have multiple OWIN pipeline segments with routing. This would allow you to have some middleware that runs first, and multiple pipelines behind this configured with different middleware in each pipeline.
Related
my application requires an authorization code grant flow integration with Cognito and the website responded to me that Auth-Code accordingly.
https://<poolName>.auth.eu-central-1.amazoncognito.com/login?client_id=<clientID>&response_type=code&scope=email+openid+profile&redirect_uri=<redirectURI>
Now I want to know what email address has logged in. As fas as I understood, this is where I would need the JWT token.
How can I query the email adress of the token I have just received?
Any help is much appreciated!
As I was going through that, actually, I still am. I have talked a lot with Amazon Engineers for past weeks, have done a bunch of research on my own and let me clarify couple of things.
Hosted UI is a way to go if you can accept the limitations. This is after all hosted ui, you can only change that much. BUT (!!!!) and I can not stretch this enough: it works only for simple usage. If you start searching you'll see that it doesn't support CUSTOM_AUTH flows which is extremely useful if you want to implement even something as basic as MFA. So if you dream of Revolut-like login page with just phone number email verification - pity, hosted ui will not help.
Hosted UI is more than just UI! It's a whole server! That's why you can't simply replace it.
Now, as we established what hosted UI can't do. What are the alternatives? Of course, you can use other providers like Okta or Auth0, but I assume, you're here because you want to use AWS. But the recommended (by AWS) alternative is to actually implement your own authentication using Amplify SDK. It's quite simple to use, I must say that. But what they don't tell you explicitly, is that it's no longer OIDC flow. Instead, AWS suggests to use their custom flows, such as USER_PASSWORD flow or SRP (Secure Remote Password), where password doesn't fly over http(s) at all.
You might ask: can't I have OIDC with Cognito AND custom flows? Well... you can, but it's not that simple. Long story short, you can use both hosted ui and amplify and possibly create your own cool SSO. For details look at their github page where AWS Labs go through some details.
If you can't afford spending next 2 months working on SSO, but you don't necessarily need OIDC flow and get settle for another solution, you can easily go for SRP or USERNAME_PASSWORD flows.
If you're like me and you're migrating from the old legacy authentication system done... wherever (;)), go for USERNAME_PASSWORD and utilise user migration lambda trigger in Cognito, where you can automatically migrate users once they login with their old credentials! Neat
AWS Cognito is full of traps... Consider that as well
First, make sure your Cognito client includes the email OAuth scope. User Pools > my-user-pool > App client settings > Allowed OAuth Scopes.
Then, decode the id token and you will have the email. You can use JWT.io to quickly decode tokens for testing and development.
UPDATE: You can use the POST /oauth2/token endpoint to fetch the tokens. But in general, if you're creating a frontend for users, it's better to use someone else's UI. The Cognito hosted UI works, although it looks a bit dated and it doesn't support MFA/TOTP. The modern approach is to use the Amplify UI Authenticator component, which supports TOTP and all the flows you'd expect (sign-up, password reset, etc).
I have been trying to bypass shibboleth sso for a specific user. Only one user need password authentication to an application running behind Apache reverse proxy. Rest all users need to go through the SSO login.
I tried tweaking few attribute-map files, but in vain.
Any idea on the shibboleth config file to modify for bypassing sso for a single user. Any suggestion on this is greatly appreciated.
Do you have code that constructs an "application session" from headers/environment variables within the app, or does the app directly access the existence/absence of the headers/environment variables set by Shibboleth?
If you have an external application session, then you just need to deploy some code to a separate path that's not protected by Shib, but some other means (maybe even Apache Basic Auth), that'll construct the relevant session cookie for the application and do the redirect.
If you're using the existence of the Shibboleth session info directly in the app, then you're probably better off just asking the IdP for an account.
Regardless, you're in the territory of building a back-door... so you must exercise extreme caution to not implement a vulnerability that can be leveraged in some way, and frankly StackOverflow doesn't know the intricacies of your application well enough to give more than general suggestions.
I suppose the short answer is... I don't think you're going to find a short answer.
I have a Web API application and I want to secure that. I've been reading about ThinkTectures IdentityModel and IdentityServer for authorization (OAtuh2) and I think this is what I need.
I'm just not really sure where to start with this. There are so many solutions available that I'm not sure what to use.
I think I need to add ThinkTecture.IndentityModel to my Web API application right?
Should I then download ThinkTecture.IdentityServer2? Or do I need Thinktecture.AuthorizationServer as well? I'm kinda confused there.
In the end I want my Web API application to be able to login into a identity server which returns claims that belongs to that user.
Could anyone tell me where and how to start with this. I need a push in the right direction.
For starters I already added ThinkTecture.IndentityModel to my WEB Api application. What else do I need to do?
I'd suggest starting with the wikis of each project. They go into details about the purpose of each project and how to get started:
https://github.com/thinktecture/Thinktecture.IdentityServer.v2/wiki
https://github.com/thinktecture/Thinktecture.AuthorizationServer/wiki
I am developing a google chrome extension that needs to communicate with a nodejs server. I was wondering if its possible to use everyauth package to simplify authentication. For starters, I just wanted to use simple password based authentication. But from the examples and the documentation ,as well according to my trial, it seems to me that everyauth is designed to be used for a webapp and gives me errors if i don't set the getLoginPath. Also i am not sure how to configure everyauth to send the user details or errors after user authenticate in a json payroll rather than redirecting user to a particular page. This is my first project with node.js and I am looking for some advice on how to go forward with this. I am open to using some other package/library that provides such authentication,
Since you are open to using other modules, as the developer of Passport, I'd suggest you look at it: https://github.com/jaredhanson/passport
Passport is designed to be a simple and unobtrusive authentication library, which makes it easy to get up and running quickly. It's also modular and extensible, which allows it to adapt to your applications needs over time.
The examples provided, along with the local strategy ( https://github.com/jaredhanson/passport-local ) are enough to get you started with username/password authentication. Let me know if you have any feedback or questions.
I was able to accomplish a REST-only interface to everyauth by overriding its handler methods: https://gist.github.com/2938492
Why hello SOers. My question today is about authentication endpoints and the architecture surrounding them.
Most web frameworks and applications I've encountered seem to have a single URL or endpoint to deal with 'authentication' - e.g. processing authentication tokens such as usernames and passwords, and doing something with them.
It seems to me like this causes a lot of follow-on work, like for example if you hit an auth-required URL, the system needs to pass that URL to the authentication endpoint in order to redirect you back there after authentication and authorisation.
Why not simply listen for authentication tokens on EVERY URL endpoint? With a modern MVC framework utilising a PageController or FrontController pattern this should be simple.
Am I missing the downsides of such an approach? Do some frameworks already utilise such a system? Opine me!
Why not simply listen for authentication tokens on EVERY URL endpoint?
Ignoring the word end-pont for a moment, that's what the out-of-the-box Microsoft Forms based authentication does; in the config you specify the parts of the site you want to protect (like the "admin" folder, whatever), you can have as many of these as you like.
When the user hits anything covered by that (as long as IIS pipes it to the ASP.NET processor) they will need to be authenticated (if they aren't already).
I would imagine the ASP.NET MVC works in exactly the same way.
Not sure if that answers your question (?)