I was wondering (before I try implemnting somethign along this path) about an approach.
Lets say I have a complete working OAuth2 system (using spring boot and spring cloud but not spring cloud security). This, so far has worked quite well and supports several different grant types.
What I am interested in is the possibility of hand creating the JWT in certain special cases and then utilizing this token with spring security.
I looked at jose4j and it seems like i should be able to use this in place of the authorization server portion of the system. Note that the goal of this was where i had to create a token that would have normally be generated by the authorization server.
You might want to look at TokenEnhancer or in particular JwtAccessTokenConverter. The latter one also provides encode/decode methods you can overwrite to use custom libraries for encoding/decoding of tokens or to add custom properties.
Note: Make sure to check the signature of the tokens!
Related
Faced the problem of differentiating access rights of different user groups to the same objects in the database. I use Spring Data JPA, Spring REST and Spring Security. The front end will interact with the REST API and render everything on the client side. It is necessary to differentiate the rights to access REST API methods for different user groups. Until this moment, he posted #PreAuthorise annotations on repositories and their methods. The problems started already at the stage of writing tests, started looking for solutions on the Internet and came across an interesting answer to stackoverflow: https://stackoverflow.com/a/21577081/13226066. It says that repositories are not the best place to set rights, use services instead. Please tell me where you can read about such an architecture, preferably also with examples. And then, I feel, I shoot myself legs with my approach.
I think there should be some kind of layer between the repository interface and the controller, which Spring Data REST automatically generates
Ok, so I'm struggling a little bit with trying to get a authentication process in my ASP.NET MVC5 (Web API 2) project. To start, here are some requirements:
I can't use Entity Framework (all access to the DB needs to be done through stored procedures)
Needs to target .NET Framework 4.5.2
I am not using ASP.NET Core
I would like to be able to use Bearer (or similar) tokens for authentication
I would like to invalidate tokens if a user logs out or automatically invalidate them after 24 hours
I would like to pass (and receive) XML when sending requests to the "login" (or "token") endpoint (note that ideally the solution should respect the "Content-Type" and "Accepts" headers, so if I send it JSON it should respond in JSON, and if I send it XML it should respond in XML)
I will not be using external providers (e.g. Google) anytime soon (maybe never)
I would like to use the <Authorize> attributes to help with protecting other endpoints
I am using VB.NET, although answers to this question can be in C# (I can convert them or rewrite them to suit)
I would like to store the tokens in the database so I can record which user is doing what within the API
(note that there are lots of reasons why I can't change the above)
I've tried to do this with Owin (OAuth) but I've found the following issues when comparing this to the requirements:
I can't seem to send the token endpoint any XML
Responses from the authentication endpoints (both successful and unsuccessful) are in JSON
I can't invalidate the tokens when logging out
I am happy to move away from OAuth if that is the best way to go for what I want. I would prefer to use Microsoft built nuget packages (ie no third party solutions) or I'm happy to partially roll my own solution (I would like to leverage as much of in-built or Microsoft built code, including Identity and Claims as possible so I can minimise testing efforts).
I have read numerous StackOverflow questions about this and search heaps on the internet, but most articles stick with OAuth despite the above issues or they rely on EntityFramework. My current solution uses the code from here (pretty much copy/pasted with some custom code in ApplicationOAuthProvider.GrantResourceOwnerCredentials()): https://www.codeproject.com/Articles/1187872/Token-Based-Authentication-for-Web-API-where-Legac
Thanks for the help!
I did some more extensive research and it looks like OAuth is not applicable for my specific situation. Although it seems like a nice authentication method, I really need to invalidate tokens via the DB, and I need the API to always send/receive XML (these are apparently not applicable when using OAuth).
To solve these problems, I have rolled my own token-based solution that creates a hashed token on the client side, so I never send passwords over the wire (which is a little bit nicer) because the token is generated on the client side (note that I am controlling what happens on the client side - these are all in house clients and I am writing the libraries these clients will use). This involved me creating my own filter which inherits System.Web.Http.AuthorizeAttribute.
If anyone stumbles across this question and provides a really good answer, I'm more than happy to mark theirs as accepted.
I want to setup a public form to write to Firebase via the Angular Firebase plugin AngularFire but it feels like there needs to be some security added so that data is only posted from that form, I can't see any interface to Whitelist a Domain/URL. Is there a way to only accept writes from a specific Form/URL without getting the User to login first?
Nope.
But it wouldn't help in your scenario anyway: when you're using Angular, all code is running in the user's browser. It might be served from your domain into that browser first, but just as easily the user might have saved the HTML locally and started running it that way.
It sounds like you're trying to secure things so that only your code can modify them, probably because you think that your code is the only thing that can be trusted to follow some of your application-specific business rules. Instead of trying to limit access to just your code, I'd instead recommend capturing the business rules server-side. Firebase has a very powerful security and data validation model just for that purpose. See https://www.firebase.com/docs/security/guide/
Once you enforce these business rules on the server, it doesn't matter how someone access your data. They could be using your code - or somebody could have taken your code (or an API that you've documented) and written a third-party application. Either way: the (security and validation) rules will be enforced by Firebase, so your data will stay valid and secure.
I have a product which consists of internal ASP.NET/MVC web sites all using WIF to enable SSO through a custom STS/IdP service. We now have a new partner site hosted outside our network on another domain and would like to enable SSO for users as they navigate between the sites. The new site uses different technologies (e.g. python) but we assume we can create a trust relationship using SAML standards as the protocol.
With SAML as the underlying protocol we assume this can be achieved but we cannot find any guidance on patterns for implementation, best practice guidance, etc... Can some recommend some resources on how to establish this type of cross-domain trust?
Note: While other options like OAuth could address this, we would prefer to stick with a SAML-based solution
Does your custom STS/IdP service support SAML?
On the python side, they will need a SAML stack. There's a number around - refer Introduction to OneLogin's SAML Toolkits e.g. There's a good diagram there as well that shows the login flow.
Then you need to get the python SAML metadata and give them your custom STS/IdP SAML metadata.
Import on both sides, configure whatever assertions you need and you should be good to go.
You'll also need to sort out the signing certificates that go into the metadata.
Example of process using simpleSAMLPHP - Configuring the SP
Following provides excellent example of SAML implementation:
http://www.codeproject.com/Articles/56640/Performing-a-SAML-Post-with-C
We used it in our project and it worked fine.
I'm going to build an API for a web app and I'm interested in what people can suggest as good practices.
I'm already planning to make it versioned (version 1 can only control certain aspects of the system, version 2 could control more, but this may need a change in the way authentication is performed that would be incompatible with version 1), and the authentication will be distinct from the standard username/password people use to log in (if someone does use a malicious tool it won't open them up to full impersonation, just whatever the api allows).
Does anyone have further ideas, or examples of sites with particularly good APIs you have used?
Read the RESTful Web Services book, which give you a good overview of how to use REST in practice, and get to up to speed quickly enough to get started now, with some confidence. This is more useful than just looking at an existing API, because it also discusses design choices and trade-offs.
1) Bake the version number directly into the URL rather than passing it as a parameter, since that gives you complete freedom to change the organization of your API namespace with each version bump.
2) Keep your URL rewriting rules (if any) as simple/lean as possible (but no simpler), while making your URLs as beautiful as possible (but no more).
3) Always look for the best HTTP status code you can find for each response (and don't forget about 202 and 207, for example).
4) Implement fascist parameter validation logic, and informative error messages.
5) Use HTTP request headers where appropriate instead of parameters (like Accept, for example, to allow clients to specify the desired data format of the response).
6) Organize your "nouns" in such a way that the URLs used by different client audiences are separated near the "root" of your URL tree (this makes it easier to enforce different authentication mechanisms for those different audiences if needed, or even map different portions of your URL tree to different servers).
7) If you're serving regular web pages off the same domain as your APIs and use the same authentication credentials, require an X-Requested-With header in your API requests so as to avoid XSRF vulnerabiities.
I would take a look at proven APIs:
YouTube API
Twitter API
There's a lot of argument about whether these APIs are "good" but I think their success is demonstrated, and they're all easy to use.
Use REST.
RESTful web services architecture is easy to implement and uses the strengths and semantics of HTTP for what they were intended. It's resource-oriented, just like the web itself.
Amazon Web Services, Google and many others offer REST APIs to interact with their products.
Use REST.
Read up on standards for APIs, or copy the ideas from one of the popular ones.
Be careful when authenticating users.
Start very very simple.
Build a site that uses your API (even if it's not useful) to check things work. Perhaps you could build a mobile version of the site or something that forces you to use the API in a lot of depth.