I have some questions regarding Identityserver4 in the following context:
I have a number of domains (domainA, domainB, domainC ect.) and I’d like all of them to use Identityserver4 for authentication, but I’d like only one implementation of Identityserver4 (with asp.net identity and EF) and have the all domains use this implementation as clients. All domains is in a hosted environment with MS SQL as database, if that has any relevance.
Question 1:
Can IdentityServer4 run in a subfolder/area of domainA, and if so what are the necessary steps for getting this to work, e.g. the endpoints shown in the .well-known endpoint?
Question2:
What are the pitfalls, if any, in hosting Identityserver4 in a subfolder/area under domainA, and also having domainA use Identityserver for authenticating users for the rest of the site, and how to avoid the pitfalls if there are any?
The authorization part that permits one user to do this and not that, and the opposite for another user is not the concern of Identityserver4, but the respective domains/sites own responsibility as I understand what I can find online. In order to make use of roles and roleclaims in asp.net identity core 2 in each domain/site there has to be a user in that domain/site, that has a reference to a user in Identityserver4 in order for the domain to use Identityserver4 for authentication.
Question 3:
How do I avoid that the user must register both on the domain and in Identityserver4, one registration would be preferable and have the other made behind the scenes along with the reference?
I hope someone can provide the answers to one or all of my questions. Links to relevant blogs etc. are welcome, but I have scoured the web to find useful answers without any luck – hopefully some of you have better search engine skills than me.
Q1
Yes you can. IdentityServer is OWIN hosted environment, thus it will be working as a middleware for your domainA, if you set it up so. Having a public endpoint entirely depends on your domainA.
Q2
The possible problem you will possibly encounter would be performance issues. your domainA is going to receive requests from domainB and domainC including, of course, domainA itself. And IdentityServer's checks-up such as authentications, validations, issuing tokens could be obviously time consuming jobs compared to the plain HTTP requests.
While the middleware is doing its job, the performance will hit slightly lower rate then domanB and domainC. But this is a necessary, unavoidable backfire because you added one another layer in your HTTP windows to deal with the authentication / authorization / validation issues on your service endpoints.
You may want to scale out your IdentityServer if the traffic gets much more huger then you expected and you feel your authorization server is dragging the whole services down. I recommend you to perform some stress tests beforehand and compare the performance differences between the services using the identity service and the services using none of that.
Q3
This could be highly opinionated answer. But as you mentioned ASP.NET Identity and EF I think you already know the answer. It seems that you're going to manage the token and identity information in your own hosted DBMS. Then consider it done with the possible duplicated registrations. Your DBMS and your implementation for storing and fetching such data will do it for you as long as you've done it right.
If you're not going to use DBMS for the identity and token data, and use a cache or a file system instead, then you will have to pour some efforts into the implementation in order to guarantee concurrency on the transactions for such data.
Related
All of the MSAL documentation wants me to use a prefix such as msalGUID:/// when authenticating back to the local device.
Then there is the oddball url urn:ietf:wg:oauth:2.0:oob that appears by default in the MSAL portal.
Since every URL I list there is essentially a backdoor into my application, I want to understand the security benefit of each option.
Why should I use the documented msalGUID:// scheme?
Should I not use an iOS Universal Link / fully qualified URL?
What is the benefit of the urn:ietf:wg:oauth:2.0:oob, and https://login.live.com/oauth20_desktop.srf?
What should I be aware of w.r.t. interactions with Microsoft Authenticator, which likely depends on this?
Background
There's a few attack vectors & usability cases that come into play when considering the redirect URI your app will use.
First, is your app going to be signing in users from an authorization agent that is not sandboxed to your app. If you're using MSAL, then the answer is almost always yes (unless you have explicitly opted to use in-app WebViews).
Cases to consider
If so, then you have two cases to consider: accidental collisions of redirect URIs (usability issue) and malicious apps intentionally trying to intercept a user being redirected back to your app (security issue).
Case 1: Naive apps
To address the former, MSAL has chosen msal<ClientID>://auth as it's unique to each app registration. There's a high amount on randomness in this format (that is lost with urn:ietf:wg:oauth:2.0:oob) which prevents the scenario in which multiple apps on the device are listening on the same URI and "accidentally" get the response. For a user, this is extremely frustrating and would impact their experience with their app. To summarize the best practice to address this, use a highly random URI that avoids accidental collision with other apps.
Case 2: Malicious apps
To address the latter, MSAL implements the Proof Key for Code Exchange (PKCE) protocol to eliminate this attack vector. To expand on the scenario, it's similar to the above scenario, except for the app has captured the response intentionally and intends to exchange the authorization code on your behalf. With PKCE, only the app that initiated the request can exchange the auth code.
Summarizing answers
To quickly answer your bullets,
Covered above.
If you're familiar with universal links and how to setup the necessary steps, this may be a good option for verifying that your app registration is only used by you.
These are intended for apps using in-app WebViews where there's stronger security guarantees related to the fact it's not leaving the app.
MSAL does not currently integrate into the Authenticator to complete auth requests. When it does, apps will likely be required to complete an enhanced registration related to redirect URIs similar to ADAL's requirements.
Similar questions have been asked before, but this a one is a little different. I created a REST API to send an XML document with `POST. I send data from my (Windows) application to the servers, which includes: open time, operating system, version, etc.
I have one problem though. How can I make sure people can't use the REST API? How do I know that the information sent to the server is from an application and not from someone who knows the URL? How do analytic software companies solve this problem?
Thank you.
Update
I would like users to use my application without having to log in. I am pretty sure that companies that create apps that do not force you to log in are able to see whatever you are doing.
Well there are several way to secure your service.
You can always setup authentication & authorization for the service - this way the service will be available only to registered/known users.
Here are links few links for more details:
Best Practices for securing a REST API / web service
http://www.stormpath.com/blog/secure-your-rest-api-right-way
Also there are less sophisticated ways such as setting firewall rules to allow connections only from certain places -- I don't think it is a recommended approach.
I've created a angularjs app which uses php for handling the database queries and enforcing an authentication schema.
When the user logs in into the app, he does so in php and php fetches the user data into a session. Then angularjs issues a http post request to a php page to read the fetched data.
After that, whenever a user asks for data, angular issues a post to a php page.
I'm considering using a framework for doing the authentication and the database queries in a better way. My security knowledge is primitive and I fear that I have mistakes in my code.
After doing a research I found laravel which seems straightforward and easy.
Now my questions are:
Can a php framework such as laravel do these things for me?
Is there something else I could use to have people authenticate and making sure that they are doing the CRUD operations they are authorized to do?
What are the keywords I'm searching about, is it routing, is it php restful? I'm asking in order to do further research on the matter.
Is there any other way in which a SPA could work with CRUD operations and Authenticating in a "safe" manner using php?
I know that the above questions are not programming questions per se, but I don't know where to ask (because I feel I cannot communicate what I want to learn about/ *that's why the keywords question above).
Thank you
There's basically two kinds of relevant "routing" both based on URLs, either client side or server side. AngularJS has the $routeProvider which you can configure so when the location changes (handled by $location) the client side template and controller being used also change. On the server side you may have redirects or "routes" that map a URL to a particular PHP file (or Java method) where at the destination it parses the incoming URL to get extra information/parameters.
I know nothing about laravel, but googling laravel and authentication came back with this which looks promising:
http://bundles.laravel.com/category/authentication
I also know things like Zend framework provide many similar options for plugging in some authentication code.
Ultimately if you're writing the CRUD operations something in your code is going to have to do deal with the role based execution of code or access to data.
RESTful is it's own thing. At a very basic level a RESTful interface uses HTTP "verbs/vocuabulary" like PUT, POST, DELETE, GET (part of the request headers which is just data that comes before any body data in the request) are given special meaning like update an entry etc. It's mostly orthogonal to the issue of authentication though if you do true REST I'm not sure if using the SESSION for maintaining authentication would be allowed since it's not completely stateless in that case (anyhow just an academic argument). Point being you can use the other ideas of REST or use some implementation that is "RESTful" and it can be written in any language or you can choose not to do this, either way you still have the issue of controlling resources (functions/methods/data) that you want to control and this issue is not the same as choosing RESTful or not RESTful (if you wanted to keep true to REST for reasons of scalability across a cluster of servers etc. you could follow guidance here How do I authenticate user in REST web service?). Also to note here the $resource in AngularJS provides an abstraction above $http specifically for handling restful services.
IMHO you should be searching for two things
1 php security/authentication
2 php hacking/hacks/vulnerabilities
You can simply write your own authentication mechanism using a session to keep track of the signed in user. http://php.net/manual/en/features.sessions.php There is no difference in a SPA vs a traditional web app as far as the server is concerned, these are simply differences in the client side code.
Any security you intend on putting in place is really only as good as your understanding of that security. I wouldn't trust someone else's plugin from the internet to handle authentication for me unless time was an extremely critical factor and security not so much. One thing that you hadn't mentioned but I think is worth looking into and necessary for any of this to really be secure is SSL. If you don't have your data encrypted there is always a possibility of a man in the middle attack (someone getting the plaintext username and password as their submitted to the database) or session hijacking (someone getting the sessionid of an active session then using that to act as the original user). Basically I would suggest you keep doing research regarding best practices and personally look over any code you plan to use to be sure you understand how it's working and what kind of security it provides you with.
I also wanted to mention, though it's a bit off topic languages wise, that Java Spring has some really nice stuff for dealing with authentication and handling access to services and data. If security is a major concern I would probably strongly consider running a Java server (not to say Java has never had it's issues or that it's automatically more secure but there's a lot of production code that has withstood the test of time). There's the free Tomcat J2EE Server or IBM WebSphere if you need to massively distribute an application. If interested search for Java, Spring, Hibernate (ORM), MyBatis, Data Access Objects. Those are all the parts (some optional) I can think of you would need to put together a service layer in Java. Good intro in the video on the left of this page:
http://static.springsource.org/spring-security/site/index.html
Also SSL isn't a silver bullet, but every layer of security helps.
Kevin Mitnick said in one of his books that lots of places have "hard-shell candy security" (paraphrasing) where breaking the outer layer means you get to all the mushy goodness inside. Any direct answer I would bank will result in this type of security.
Depending on the scope of the project it might be necessary to have security professionals do penetration testing on the system to determine if there are vulnerabilities so they can be plugged.
I'm about to build a community platform from scratch. We are going to create the WebServices first and the community might have some third party components, so having solid WebServices is a good idea anyway.
Since the service is stateless we need authentication for every single call. Is it a good idea to implement the OAuth protocol for our service provider to perform this task although we are the only consumer right now?
By the way: We will deliver a mobile application before a website is launched.
The whole point of OAuth is to allow other websites (consumers) to get access to your data (you are the provider). Since you are the only consumer of your data, there is no need to implement OAuth at this stage of development.
Be lean, build something fast and put it in front of users/testers. Only at this point you will discover real bugs and get a feedback on the service so that you can improve it and steer the development in the right direction.
Note: OAuth as provided by App Engine (second paragraph) only supports users with Google Accounts (even if OpenID is used).
From my experience I created the REST WS in a authentication agnostic way: jersey methods accept everything, then there are several filters in order to validate the requests.
I used OpenId authentication for the web part, OAuth and BASIC AUTHENTICATION (with SSL) for API.
Probably it is not needed to create everything from the beginning, but remember to de-couple as much as possible your REST endpoint from the authentication: you will have a great benefit when you want to release APIs.
Last "philosophical" thing: OAuth is not totally stateless, in fact you have a temporary token that authenticates a user and it is similar to a session in the browser!
I'm currently in the process of dating the data from other networks by the use of Gigya to allow users to login to my site and then post the data with php to my database.
I don't know if this is the best option available as they aren't precise on installing it to post the data etc; they put everything in sub sections on how to do individual things.
I'm curious if there is a custom tutorial on using a different service or making it myself. I've read the API's and developements of some of the site, and facebook using JSON apparently, which I'm not familiar with.
You have two elements in your question.
First, authentication. There are several services offering you multiple networks authentication, but using several of them for a single user is not as common: you will most likely have to do it yourself. To handle multiple identities in parallel, your server will have to store them and manage the session on its own. Gigya is one authentication solution, there is also two other good ones:
http://www.janrain.com/products/engage/social-login
www.clickpass.com/docs (still under development)
Then, using api. To do that, you will have to decide what to do and then call the API yourself using Javascript SDKs or server-side ones. Notice the authentication will need to provide you with oauth (most common authentication method) keys to post messages or fetch data. More here:
developers.facebook.com/docs/api
developer.twitter.com/doc
One thing worth noting about Gigya. The have a function called "showAddConnectionUI" which basically lets users establish simultaneous connections with multiple social networks. For example, once a user authenticates to your site w/ Facebook, they can also connect with Twitter and Google if you want to allow this. The nice thing is that Gigya manages these identities for you so you technically don't have to implement anything on your side... just call their getUserInfo function and they'll return a collection of identities.
Not sure if that helps... we use this functionality on our site and it works well. Here's the link to showAddConnectionsUI:
http://wiki.gigya.com/030_API_reference/010_Client_API/020_Methods/socialize.showAddConnectionsUI