I am writing an app that uses Parse Server, with Auth0 as the authentication provider. For unrelated reasons, we need to use Auth0 rather than Parse for user management.
I'm having trouble figuring out how to "link" a user authenticated via Auth0 to Objects in Parse Server. Without this, the authenticated user will not have permission to write to his/her Objects on the Parse Server. I believe my issue is similar to this question, which has no solution: here.
I have found many articles discussing the migration of users from Parse to Auth0, but am finding surprisingly little documentation on how to link those users to Parse. There is one article (I believe written by the same person who posted the question I linked to), but I couldn't get it to work, and it involves storing passwords in cleartext in Javascript.
I thought to create a default Parse user that would simply own all the objects in Parse. This would be invisible to the authenticated end-user so they wouldn't know, but that's just security by obscurity and doesn't seem like a good approach.
If anyone has suggestions on how to approach this, or has done it before, I'm interested to read your suggestions. Thank you very much.
Auth0 supports the most common and used authentication protocols (OAuth2/OIDC, SAML and WS-Federation) so configuring an application to rely on Auth0 is really easy when that application already talks one of the previously mentioned protocols.
According to the Parse Server Wiki, it does support custom authentication leveraging OAuth so that seems your best starting point for integrating Auth0 with a Parse Server based application.
It is possible to leverage the OAuth support with any 3rd party authentication that you bring in.
Disclaimer: I never used the Parse service or Parse Server so I'm assuming that when you mean linking Parse objects to users this can be accomplished by simply having an authenticated user in Parse and the identity of that user is just verified and proven by Auth0 instead of something like built-in username/passwords managed by Parse itself.
Related
I have an ASP.NET 5 (RC1) application for which I am trying to set up authentication and authorization. However I am confused and overwhelmed by all the varying authentication and authorization information online in as it pertains to this platform. Much of it seems either hopelessly out of date or simply doesn't seem to apply in this particular usage scenario. Right now, I'm not even sure what the right 'terminology' to use for the question I am trying to ask, but I digress.
What I am trying to accomplish is a system whereby users are authenticated/authorized via Azure AD (B2C?), with additional user profile information stored in a database. However, the user context in the controllers is accessed in a consistent way using what I presume would be a custom ClaimsPrincipal/ClaimsIdentity? I would imagine this should be as simple as adding an 'authorize' attribute or something similar and accessing the ClaimsPrinciple.Current.Claims.
I have used ASP.NET Identity in the past, but many of the examples I have found aren't using that. Most are simply using the UseOpenIdConnectAuthentication middle-ware. I see that ASP.NET Identity is still available but I'm not sure it applies in this scenario. I also found a couple posts on here suggesting using a custom ClaimsIdentity to accomplish this, but I am having trouble finding useful up to date examples. BTW, I realize that much of this "profile" information can be stored as custom attributes in azure ad but the way some of the information is used within the application prohibits all of it from being in azure (i.e. EF linq joins and such).
Please, tell me if I am even close on some of this. I know this is a fairly new platform and the information is sparse, but certainly I'm not the only one asking these questions.
Just calling out an excellent article Identity management for multitenant applications in Microsoft Azure.
A lot of your questions are answered there.
e.g. you can augment the claim in the OWIN middleware AuthenticationValidated event.
ASP.NET Identity is claims-based in that the attributes are delivered as claims but authentication is on the DB, not via external IDP like Azure AD.
B2C is a special case in Azure AD - used for many (millions!) external users who can self-register and self-manage e.g. SSPR.
B2C uses a separate tenant to the normal Azure AD one and the users have no access to things like O365 or any SaaS applications.
Something seems to elude me with regard to xAPI. I am going to try and keep this really simple.(and maybe even stupid)
What I understand to be true...
Any Tin Can implemented content can be launched with a launcher.
The launcher is provides endpoint and auth information
The endpoint DOES NOT have to be an LRS. It can be a script which then passed to the final endpoint, which is an LRS.
The LRS, in this case private SCORM Cloud(sandbox), cannot receive statements without basic auth.
What I need to know...
Does the LRS generate OAuth tokens?
How would someone pass the statement from Captivate, Storyline, lectora files to a the TinCan_PHP for handling secure connectioni to the LRS?
Why would I use TinCan.JS, when the basic auth information is easily broadcasted to the end user, which could then be used to cause harm to the LRS?
Am I completely off track?
Thanks a lot...
Just some clarifications for future users on your understanding...
A launcher may provide endpoint and auth, that is one scenario and is probably based on the launch guidelines that came out with the 0.9 spec. There are other ways to handle the handshake, for instance how cmi5 does so (which isn't necessarily any more secure other than the fact that the credentials can only be requested once and are intentionally denied certain privileges such as voiding of statements).
I would consider your "script" a 'non-conformant' LRS in that it is receiving statements (in the form of xAPI requests), but doesn't provide full LRS conformance. SCORM Cloud's LRS can't receive statements without some authentication, but you are correct basic is preferred because OAuth there doesn't make much sense for production.
For the questions...
Yes, the LRS generates OAuth tokens, but for the most common approach the content has to have an already established relationship with that LRS and the OAuth based account has to be on the LRS (or a system the LRS is tightly coupled with, like an LMS) not with some OAuth provider in the wild (meaning you can't use accounts on Twitter, or Facebook, or Google, etc. which is the part that is often confusing for people).
They wouldn't, those products all already support direct communication to an LRS via the launch guidelines (Basic Auth), any system they are communicating with has to have at least enough LRS functionality to support them which includes the State API besides the Statements API.
TinCanJS in and of itself isn't a browser only solution, there are people running it on the server side so the language is really a separate issue. It is also possible to use TinCanJS outside the common launch paradigm, and in such situations it is possible that the user has an individual credential with the LRS in question (or a system that is coupled with the LRS) and they enter it themselves. A bookmarklet is a good example application.
The bottom line with all sets of credentials is to make sure your application is conversing with the LRS over https in which case the credential used isn't in the open, then check with the LRS provider to see if it is possible to use credentials that are short lived and have limited permissions. There is little "harm" that can be done to a properly implemented LRS short of voiding of statements or overwriting (deleting) of stored documents, both of which can be limited when using a proper permissions scheme and limited credential.
To answer your question, yes you are completely off track! :-)
If you're sending statements from a javascript based e-learning course to somewhere, then than connection is inherently not secure. Adding another (secure or otherwise) link in the chain after that insecure connection doesn't add to your security. You may as well send the xAPI statements directly to the LRS.
You may as well use Basic HTTP authentication too. Firstly, that's what all the authoring tools support, so you kind of have to. Secondly, using OAuth instead of Basic Auth for client side connections is like using a key lock instead of a combination lock and then leaving the key under mat. A key lock (OAuth) might be more theoretically secure than a combination lock (Basic Auth) but not in practice if you leave the key under the doormat (embedded in your client side code).
See this SO question answer for three options of what you can do about xAPI authentication security.
And just for the sake of completeness: yes, in the case of OAuth the LRS generates the tokens. See the xAPI spec for the most up to date details.
I'm new to WebAPI and before I dive too deep, I would like to first secure the Web API application first. After days of research, I just found one approach that's straight forward.
Looking over this post How to secure an ASP.NET Web API, I understand overall how it works and it's great there is a github source for it too. (Most answers I found just describe the generic concept with no code to back it up)
My question is, how do you store this "Shared Secret Key" on the server which typically is user's password? I'm doing a ASP.NET MVC 4 app with provided membership provider and it stores the user passwords with salt.
Obviously, the salt value is randomly generated per user and it's not likely the end user knows what their salt value is.
So then, what do you do?
PS: Am I missing some well known frameworks that handle this? I know Microsoft encourages mobile app developments and want developers to create new apps, but how am I suppose to do this when I can't even build authentication for Web API easily? Sorry, just a bit frustrated.
HMAC is not typically used for authenticating users to an API. It's typically used to authenticate "trusted" systems to an API. Example: Company A wants to access Company B's protected API, but doesn't need to authenticate at the user level.
When doing HMAC, you need to have the shared secret available in clear text on both the client and server so that both systems can create the exact same request signature hash. Although you may want to store the shared secret in an encrypted format, it must be a two-way (reversible) encryption.
I am trying to integrate two separate web applications - one is an existing custom web application with it's own security paradigm and the other is a reporting platform (JasperServer). I want to be able to use Jasper's web services interface to integrate the reporting functionality into our application. Our security model is complex and is home grown but I think there is hope.
We set a cookie that is an encrypted string containing a web service URI as the authentication source and a token which is stored in the database that is created when the user logs in and is destroyed when he/she logs out. I think I can leverage this to implement a kind of SSO in Jasper since it uses Spring Security.
What I THINK I should do is implement a pre-authentication filter that checks for the cookie I mentioned above. It could then decrypt it, make a web service call to the authentication source provided to verify the token is active in the database. If it is, that token can be used to point to user and role information that could be returned as a UserDetails object.
Unfortunately, I know enough to be dangerous but not enough to be effective. Am I on the right track? Does this solution sound tenable? If so, where would be a good place to start and are there any examples of something similar you could point me to? I've searched around quite a bit and have found nothing that quite fits the bill.
Thanks in advance to any and all who can provide me a glimmer of hope
Cookies are tied to a domain/subdomain/path and port. It is possible to set a cookie at the domain level so if you have something like webapp.mydomain.com and jasper.mydomain.com you may be ok assuming they are on the same port.
However be very careful about implementing your own SSO/Authentication framework. It requires a great deal of thought. As it stands your proposed implementation would be vulnerable to: replay, man in the middle, and XSRF attacks ... there may be other vulnerabilities but these are just 3 that come to mind ... sorry! :D
Our company has a web application that is only used internally by our employees. We also have Google Apps Premier Edition. We would like to make it so our employees can log into our private web application using the Google Apps account that they already have.
Requirements: We want to display our own login form. We don't want to pass the email/password in plain text through the internet.
Which authentication mechanism should we use to achieve this?
Note: our application is written in PHP using Zend Framework (if that matters).
I would look into some combination of OpenID and your domain users (i.e. only let those at domain.com can log in).
Google API
They also have libraries for PHP and other languages that you can leverage to make this happen.
EDIT:
Some more info
When it comes to integrate Google Apps and an internally used private system, we simply have two options.
Use Google as the authentication center. Modify the private system to authenticate at Google's server. We could use OpenID or AuthSub. Check http://code.google.com/apis/accounts/docs/OpenID.html and http://code.google.com/apis/accounts/docs/AuthSub.html for more information.
Use the private system as the authentication center. In this case, we have to implement SAML protocol in the private server and configure Google Apps's SSO settings. Check http://code.google.com/googleapps/domain/sso/saml_reference_implementation.html for more information.
It is easier to accomplish SSO with the first method since there's already bunch of OpenID libraries out there. But, as you described in the requirements, you want to use your own login form. So I guess you have to go with the second method.
BTW, if your private system has to get or set information from Google, you may want to use OAuth for authorization. See http://code.google.com/apis/accounts/docs/OAuth.html for more information.
Use the ClientLogin API, it does exactly what you're after: allow you to verify username and password. (the link goes to provisioning API doco but that is not relevant here)
Pro's:
you get to use you own login form
Cons:
you don't get SSO with Google Apps, i.e. users already in Apps will be prompted to login again (you didn't mention that as a requirement, but it seems a reasonable thing to want)
Google won't like you (they're trying to discourage ProgrammaticLogin.
you will get occasional CAPTCHA tests you'll need to show your users.
OpenID specifically prevents you from displaying your own login page, so if that's a hard requirements, Programmatic Login is really your only choice.
Going the SSO route let's you do pretty much anything, but may be a bit of overkill to take on authentication for the whole domain to make one app authenticate in a nicer fashion? If you really want to go down this route, check out SimpleSAMLphp.