So I can get all necessary data from my server when username and password are provided (zumoJwt token, user id and auth identity), but I still cannot get the user id property from the user object at the server side. I'm trying to set the user as follows:
Ext.azure.Authentication.setCurrentUser({id: res.id, token: res.token});
Where res.id is the user id and res.token is the server generated zumoJwt token.
So my question here is as follows: How can I set these values properly to proper place in order to authenticate to the server with my custom authentication service?
The Sencha Touch Extensions for Windows Azure are built to connect via oAuth to the Azure Mobile Services, and therefore only support the oAuth providers available from Azure (Facebook, Twitter, Google, Microsoft).
Calling Ext.azure.Authentication.setCurrentUser() literally does nothing except store those values locally in HTML5 localstorage. Those values might get added to HTTP request headers later (if useHeaderAuthentication is set to true)... but these Azure extensions for Sencha Touch aren't going to allow you to use a custom oAuth provider.
Does Azure Mobile Services even allow you to use a custom authentication service? I know the Active Directory integration is new, but the Sencha Touch extensions don't support that yet.
Related
I am trying to implement sso with firebase authentication and i am trying to use without using third party like okta and wanted to know is it any workaround with this.basically the use case like this
A client wanted to build a custom SSO solution and had already chosen Firebase, based on Google’s promise to rollout SSO support in the future. The client did not want migration to any other SSO provider like Auth0 or Identity Server, or to deal with user-password migration and potential related issues. They preferred instead to use a temporary, custom solution that would store user’s passwords in Firebase Authentication.
The client had several customer portals based on WordPress Customer Relationship Management (CRM) and an existing list of users in Firebase Authentication. Each time users visited a new portal, credentials were required, and again when users followed a link from one portal to another. It was not always obvious for users that the same credentials should be used for different portals.
By default, Firebase keeps authentication context for one domain but doesn’t provide seamless SSO integration between different domains. To provide this functionality, SoftServe determined that a new Firebase service should be implemented.
Using a simple C#/WPF application and the SharePointPnPCoreOnline I can call the GetWebLoginClientContext() method which opens up a window for the user to authenticate via MFA to a given SharePoint site. From that point on I can query the SP site based on the users level of access. The convenient thing about this approach is that I don't have to register my WPF application with Azure AD, give it permissions, get a client ID, client secret, yadda yadda yadda.
Is there a library that will similarly allow me to authenticate a user via MFA so that I can access the Graph API based on their permissions without the AAD app registration requirement from a C# client application? How about a JavaScript application?
This is not possible, to access the graph api, (for a work or student account) there must be an app registration to give you permissions to those endpoints. even the "graph explorer" has a registered application.
Even with your sharepointpnpcoreonline, that likely authenticates against an app registration/service principal, its just that its microsoft trusted app registrations, so it's hiding it in the background from you. if you were to check in your azure ad enterprise applications under microsoft applications, there are various service principals for sharepoint online for example.
Long and short of it is that you need to have an app registration/service principal to access graph api endpoints. you don't necessarily need a client secret though, as that depends on your specific application and the authentication flow you choose to use in your app registration.
I have enabled SSO using Azure Premium AD with Google Apps, i can login to Google apps when I go to browser and click my apps however I need to get data programmatic after I login into O365. Instead of clicking my apps i need to use a programmatic snippets (ex., javascript) query some data from google apps or any configured SaaS based apps.
You can try to use adal for js to authenticate and authorize your users. You can write a initialization functionality in your client application using javascript. When the document is loaded, check whether the user is signed in, if so, call your additional APIs, if not, use adal to login.
I want to create a client-side (server-less) application using the AWS SDK for JavaScript in the Browser. All intended users of the tool have individual IAM users and access to the AWS Web Console.
I want all API calls to be executed in the context of individual IAM users, so they are subject to each user's individual permissions, and so that I can see who did what in CloudTrail.
Since no kind of browser local storage should be trusted with persistent credentials, I cannot simply let the user enter his secret access key once and keep it.
However I guess I could request the user's access key id and secret access key on the beginning of each session, then call STS GetSessionToken with it, and only store the resulting temporary security credentials in the session storage and use that for all following SDK usage.
Of course it would be much nicer for users to be able to log in with their IAM user and password instead of their long and cryptic access key (think of mobile devices...).
Is there any kind of federated login option for IAM users (redirecting them to the AWS IAM login page), or a way to call the STS API with username and password?
Ideally, what you want is login via IAM user/password combination. As far as I am aware (and also see this) there is no standard way of doing this.
In one of my projects, I've simulated online login using HTTP client. If you can get the session token with that, that could work for you. But it does not support MFA, and is relying on the internals of the AWS authentication implementation which might change without warnings.
I'm running a webview from a cordova app and want to authenticate a user, I know they have the OAuth strategies but I need to use the email/password combination.
I'd like to keep things simple but may end up having to generate a token.
Open an InAppBrowser that loads an auth flow for firebase
Listen for that auth flow to be completed using this method: http://blogs.telerik.com/appbuilder/posts/13-12-23/cross-window-communication-with-cordova%27s-inappbrowser
Grab the result from the webview again and insert it into the webview firebase instance
I'm guessing that's not possible due to security.
My app is using Amazon login (required) so my alternative would be:
webview loads InAppBrowser with our external url
that loads Amazon auth, then generates a token for Firebase
webview listens for token and grabs it, stores it in localstorage
Edit:
In the firebase docs on logging in with a username/password, I see it returns a token for the session and more information in the authData object:
https://www.firebase.com/docs/web/guide/user-auth.html
Could I then take all the information from that object and send it back over to the cordova webview and then populate that Firebase ref with the information?
Some answers from the wonderfully helpful support at Firebase:
First:
You’re correct – anyone can make a request to sign up, and we don’t expose any capability to secure the url which people can sign up from for email / password authentication.
The main reason that we require / enable origin whitelisting for OAuth authentication, but not for email / password authentication, tends to revolve around sessioning.
The Firebase login server does not maintain sessions (via cookies or any other method), and so requests to the login server for password auth. requires a user credential (the password) for every request. CSRF is typically a risk when a malicious party can take advantage of a user’s session browser, i.e. make requests on behalf of the user to some page where cookies are automatically sent by the browser.
Furthermore, we don’t have a great way to actually do ideal origin-based whitelisting for these pure HTTP requests. We could use CORS, but would have to fall back to JSONP for older browser environments that don’t support it. To complicate matters further, PhoneGap / Cordova apps don’t have the same notion of an “origin” at all, and from the perspective of a server – the calls are indistinguishable from any malicious party making an HTTP request with the same headers.
The OAuth providers, however, use cookies for sessioning and do not require user invention for each auth. request. If you’ve approved a particular Facebook app, you won’t be shown any UI/UX or be prompted the next time that app requests your data – it will be invisible. When we do OAuth, we never have to send any user credentials to Facebook / Twitter / etc., because those are stored in browser cookies for facebook.com / twitter.com / etc. What we need to protect is a malicious party pretending to be a popular, valid Facebook app. and taking advantage of that short-circuit behavior that would get access to user data without the user’s knowledge.
My response:
So, how is that secured? If anyone can make a request to sign up from a
cordova webview (which comes from no specific url, just the app iteself)
then I can't secure from which url people can sign up from? So any site
could use our url "xxx.com" in their config and start registering
users?
That doesn't seem right to me.
I think I still need to have an external url that is whitelisted by you
guys. That would have the login form and do the auth.
But then my question is, can I transfer that auth back to my cordova app?
Is it somewhere in localStorage I can check? I'll have to run some tests.
And final response:
Sure thing – we’re happy to help. I wrote much of the original client authentication code, and can speak to the design decisions and rationale that went into it. Be sure to let me know if you have further questions there.
While we don’t store user passwords in cookies, of course, we maintain a Firebase auth. token in LocalStorage. Our authentication tokens are signed by your unique Firebase secret (so they cannot be spoofed), and can contain any arbitrary user data that would be useful in your security rules.
By default, and when using the delegated login (email + password) service, these tokens will only contain a user id to uniquely identify your users for use in your security rules. For example, you could restrict all writes or reads to a given path (e.g. write to /users/$uid/name) by the user id present in the token (“.write” = “$uid = auth.uid”). Much more information on that topic available on our website.
Your plan to spin up a server to authenticate users with Amazon and generate tokens sounds correct. This is a common pattern for our users who wish to use authentication methods that we don’t support out-of-the-box (ie Amazon OAuth) or have custom auth requirements. Note: once you’ve created those tokens and sent them down to the client, they’ll be automatically persisted for you once you call ref.authWithCustomToken(…). Subsequent restarts of the app will use the same token, as long as it has not yet expired.
This is a topic of interest to me too as I have implemented something similar , twitter digits (native android) + firebase custom login in webview.
I think, as recommended by firebase, you can use other authentication providers and then the firebase custom login.
Do you use the Amazon login in android native code ? If so after login, then generate a JWT token for firebase and use it to access firebase.
If all code is in Html/js app, then maybe you can use custom login and generate a token on your server after making sure its logged in to the Amazon.
The trouble with Android hybrid apps is the following: the JWT token (for firebase) should be created on secure system (eg. server side) not with android java code, other option for hybrid app is to do a http request to generate the token, but I find that less secure, anyone would be able to get a token by finding the URL, than I resort to generate token within android app code, you can change security key/seed for token when doing new releases.
In summary, I don't think firebase studied the problem of mobile hybrid apps.