I'm using AAD B2C to secure a JavaScript application and backing web services. Users may be associated with multiple companies, so I plan to use a dropdown and allow a user to choose which context they wish to act under.
The backend web service needs to receive the "context"... so I feel like a I need to add a value to the AAD B2C token after the user has been authenticated... or I need to call back to AAD B2C with the value somehow.
I can't find any documentation to suggest this is possible.
Is this a supported user flow?
You cannot simply "add a value" to a token. The token is created and signed by MS, not by your app.
But you can define a custom claim and have it included in the token. Let's say you name it Contexts and it will be the list of IDs or names of the companies the user has access to. After a successful login, the token with this claim is returned to your js and you can parse it to get the individual items (companies) to display in the dropdown. After the user has picked the preferred context from the dropdown, you pass it to your backend web service as an extra parameter, not as part of the token.
Managing the Contexts property/claim can be done via Graph calls - I suspect you don't want to allow the users themselves to add in there whatever they want.
They only way to achieve this scenario, where a consumer has respective access rights to multiple tenancies within your scenario, is to use Custom Policies:
Collect the users credentials and validate
Call a REST API to send back a comma delimited list of tenancies the user has access to
Display a self asserted page with 2 B2C claims in textboxes. One should be populated with the comma delimited list from 2) using InputClaims.
Customise this page with JavaScript enabled, use JS to render a drop down box with its enumeration from the populated text field from 3.
When the user selects from the drop down box, send the result using JS to the other text box that was rendered.
Use CSS to hide the 2 text boxes.
When the user submits the page, use a ValidationTechnical profile to send back the users input to a REST API to make sure the value is within their authorized list of tenancies.
Insert the tenants name into the Token using the Outputclaims section of the RelyingParty element.
The App can now know which tenancy to show, with correct access rights.
Related
I am currently studying web development at college and part of my course is to create a website for a mobile company that sells phones and they sell them online.
I'm trying to create a login and signup form but currently struggling to get my form to identify and use the email that the user inputs to send an email to them verifying that they have submitted is it possible and if so any help would be appreciated.
What I will suggest is in your server backend, whether it be PHP, NodeJS, etc
that you register the user in your database and have a boolean value named
'validated' true|false
set default to false, also generate a unique hash and assign it to that user under something like
'validate_hash':gnOOBhgenl2g432noug24g42
Use whatever function your backend server provides (or a library) to generate a unique has, and save this to the newly registered user
Then use a mail function to email the user with a link that will 'verify' them, by adding the unique has to a post url like this:
example.com/register/verify?hash=gnOOBhgenl2g432noug24g42&email=example#mail.com
Obviously you will have to create a script at that location and handles the link and checks the hash value given against the mail provided in the database
If the hash value matches, you can update the users status to
'verified'true
And they can now access services normally.
Majority of this wont need fancy outside libs or complicated coding, just follow what I suggested and google the things I mentioned if you need to figure out a particular element, or comment/msg me!
I'm using visitor_post to display page visitor posts.
right now i can get created_time, message, and id in object.
is it possible to display also the user profile picture?
The from field holds the user id, and via Field Expansion syntax you can use that to request the picture property of that:
...?fields=from{picture.type(large)}
Be aware that you will need a page access token to make this request; with any other kind of token you won't get any user details for posts on pages any more.
That of course also means that you should only do this on the server side (which you should for caching purposes anyway), because a page access token should never be exposed in publicly available code such as client-side JavaScript.
I'm switching from PayPal to Stripe so I can keep the checkout system entirely on my own sales site. While I have an intermediate understanding of PHP and API interactions, I'm so jaded from using PayPal for 3 years I can't figure out how the flow works for Stripe. Their documentation is excellent, it's more "Dictionary" like and not actual examples.
I'm looking to sell Subscription payments from my own site. You create the HTML, include the Stripe.js bit, but what's the process itself? As in, "index.php submits the checkout form, which notifies Stripe, which sends a ping back to charge.php..." etc, that sort of thing.
Where does the customer creation go, and how does it get attached to a CC charge?
Where does the confirmation from Stripe go?
Where does my price checking PHP go?
I've emailed Stripe, and while they're friendly enough they more or less just told me to go online to their documentation, which I've already spent hours in and still don't get it.
I know I'm being dumb - the tutorials online all seem to focus on Stripe Checkout, which is the popup that I don't want, not the custom HTML form.
Thanks in advance guys. :)
There are a number of different ways you can set it up. Here's how we do it in our application.
When the user enters CC information, you use the Stripe.js API on the client to submit the CC to Stripe, and it returns a token. The callback removes the CC data from your form, puts the token in a hidden field in the form, and submits the form to the server.
If you want to save the customer's CC information so they don't have to re-enter it every time, you then use the stripe-php API to create a \Stripe\Customer object for this CC, sending the token as the card parameter. This will return a customer ID, you can save this in your user database for future reuse.
To charge the card, you create a \Stripe\Charge object, with this customer ID in the customer field. The response from this indicates that the charge was successful; if there's a problem it will throw an exception.
If you just want to do a one-time charge without saving the CC permanently, you could just go straight to creating the \Stripe\Charge object, and use the token as the source field.
If you want to allow customers to have multiple saved cards, you create the \Stripe\Customer object the first time, and when they add a new card you retrieve their customer object, add the new token to the source array, and update it. Then on future charges you can specify both the customer and source fields. In this case, the source field should be the card ID of one of their saved cards.
You would presumably do your own validation of the form, and calculate the price, before calling the Stripe API from the PHP script.
Stripe do have a section with examples and sort of step by step guides for this, don't know if you found it - its separate to the API documentation and I didn't see it first time round. [https://stripe.com/docs/subscriptions/quickstart][1] [1]: https://stripe.com/docs/subscriptions/quickstart
For this to make sense, you will need to install their client library for PHP (or whatever you're using) and be familiar with PHP forms.
To answer your questions:
Where does the customer creation go, and how does it get attached to a
CC charge?
This is done using the functions from their library, see link above. The customer creation is sort of separate from the charge. You will need to store the customer ID in your database to charge them later.
Where does the confirmation from Stripe go?
This is returned in the response from the api call.
Where does my price checking PHP go?
Not sure what you mean by this. Presumably you work out the price to charge them first with your code, you can then just give this to stripe as an amount.
Hope this helps.
Scenario 1
I have a control panel interface (html/css), which is available to both a registered user and non-registered user. I'll use a client-side ajax just to check if there's a valid user session. If that returns a 200 (ok), I'll then have Angular hide the guest part of the interface, and show the user part. (Basically hides the login form and shows the user options section). If it returns a 400, vice versa.
Scenario 2
I have one control panel interface for guest, and one for a registered user. Upon requesting the control panel partial interface, I would use a server-side router/controller logic that checks for a valid user session. If it is true, response send the controlPanel-user.html. If it is false, response send the controlPanel-guest.html.
I have tried looking for proper theories for this scenario but couldn't find one specific to this situation, maybe someone here is a better Googler than I am.
Note: client side interface updates wouldn't really compromise my system, regardless whether or not the person is able to access the user-version of the html views, they would still be declined access to any API without proper server side authentication.
For my own requirements, I decided on scenario 1. For a light-data front end application, this shouldn't be an issue. Multiple templates would just increase the amount of requests and increase server usage.
Upon completion of an ajax call I would like to direct the user to an html page, but at the same time passing a hidden variable (this variable contains sensitive information and should not show up in the URL).
How can I accomplish this?
window.location.href = 'userpage.html?id=14253';
But with the id remaining invisible? Can I POST the id somehow while sending the user to userpage.html?
You should not be checking user credentials on the client side of your website. Regardless of how the ID is being passed to your script, it can be replicated without you being able to check if the request is valid.
To start being even remotely secure with what information is granted to a user, you need to be checking it via the server side. With every request, ensure the user is authenticated to view such data.
If I were you, I would look into using PHP sessions as the first line of defense for checking if a user is authenticated. Doing so will at least keep the information about a user out of a replicable space that can be viewed by the user.
Look up 'php session login tutorial' on Google and you will find plenty of simple tutorials which should get you on the right track.
Example Tutorial
No matter what, the information you pass along is insecure. You can submit a post request using XMLHttpRequest objects if you'd like (or use a framework/library to make AJAX calls) -- but the user could still spoof the data and get different results.
ID enforcement should be done in the backend. Does the requested ID match the ID of the user signed in? No? Don't show it. etc etc.