We Keep Coding

Read b2c extension attribute using Graph API in C#

We are using the Graph API in C# to read data from AD about users setup in B2C.
We have a number of extension attributes setup in the b2c environment, and we want to be able to read the values of these attributes for users in our C# application.
We can make a successful request to get details on the user using:
graphServiceClient.Users[userId].Request().Select("id,displayName").GetAsync();
Which returns the details on the attributes specified.
However, we can't find an option for getting the extension attribute values back with this request. We have included the name of the attribute using the guid of the application storing the attributes, but the attributes are not returned.
We have also tried the following request, which returns the response of "Extension with given id not found":
var extensionDetails = graphServiceClient.Users[userId].Extensions["extension_{guidWithDashesRemoved}_{attributeName}"].Request().GetAsync();
We are able to do this successfully in Postman with the following get request:
https://graph.microsoft.com/v1.0/users?$select=id,displayName,givenName,postalCode,extension_{guidWithDashesRemoved}_{attributeName}
Has anyone been able to get the extension attribute values back?

The first code is correct. You need to add the extension property into the select query parameter.
var user = await graphServiceClient.Users[userId]
.Request()
.Select("id,extension_{guidWithDashesRemoved}_{attributeName},displayName")
.GetAsync();

Ways to secure an anonymous Web API request

I have a ASP.NET MVC (NOT ASP.NET Core) single page application with angular js on the front end.
My client (browser) talks to server through ASP.NET Web APIs. Now, the web application is on https but anonymous. There is no login/ user authentication.
The web app is in the form of a wizard where user can go back and forth and add or update input fields on the web page. The form input values are then updated on the server through Web API.
I'm looking for a way to secure my Web API calls alone, especially the POST/ PUT requests. In summary, I want to prevent any user calling my Web API directly from POSTMAN or Fiddler. The Web API, though anonymous can be only called from the browser session where the request originated.
What are options do I have to achieve this?
Can I use Anti-Forgery token here (without authentication)?
One way, I can think of achieving this is to add a custom header to each request and store some kind of session key in the header. Then, validate the custom header on every request I received from client. Are any other ways of achieving this out-of-box or some proven library without going for custom solution?
If I have to go for the above custom solution, what are the pitfalls or potential issues I need to be aware of?

First of all when you remove login and there's no authentication mechanism in your application, there's really no way to secure anything, because anyone can access your APIs. I think what you want is to make sure that your APIs are called only from your own website. Unfortunately you can't completely achieve that, since your web APIs are http/https, and anyone, from anywhere (like postman, fiddler, ...) can create a http request and call your API.
All you can do is to make it harder for your API to response to requests, like using Anti-Forgery as you mentioned.
And also I suggest you add a cookie for your application and check that cookie in every request, in this case it's more complicated ( not impossible ) to call your API using Fiddler or Postman.
And last I suggest that you use CORS, so browsers would only allow your domain to call your APIs. So nobody can call your APIs in a browser from different domain.

Based on answer from #Arvin and comment from #Evk, here's how I plan to proceed:
Once, the user starts the anonymous session generate a GUID using regular Guid.NewGuid() method and save it in DB to identify the request (I'm doing this now). However, as mentioned here,
GUID can be unique but they are not cryptographically secured.
Hence, instead of using plain-text GUID, encrypt it with current timestamp as token and append it with request query string.
For every subsequent API request, read the token from query string, decrypt it and validate it as follows:
Check the timestamp. If the time difference is more than pre-defined time (i.e. token expired), reject the request
Validate the unique id (GUID) against DB
Since, I'm not using plain text GUID anymore, the URI would not easy to guess.
Additionally, with the timestamp, URI is invalidated after sometime. While theoretically it is still possible to call the API through Fiddler but this should make it very difficult for the attacker, if not impossible.
As a further security measure, I can also add Anti-Forgery token to the request
As per my understanding this helps solving my underlying problem and with this approach, I may not even need add a cookie to secure my anonymous session.
Love to hear from you all if this approach looks good and how can it be improved.

I also once had the weird need for having session functionality on WebAPI and created an OWIN Session middleware that does exactly what you're aiming for.
The library is called OwinSessionMiddleware and is available on github and NuGet.
Usage
public class Startup
{
public void Configuration(IAppBuilder app)
{
app.UseSessionMiddleware();
// other middleware registrations...
app.UseWebApi();
}
}
You can also pass some options to further tweak cookie-name, add a database backed session store (instead of in-memory), add your own session id generator (instead of default id generator which is based on GUID + secure random part generated by RNGCryptoServiceProvider).
The unique session id itself is stored as a secure cookie and the session is restored automatically by the middleware on each request.
There are extension methods you can call inside your API controller to get and set session data:
public SomeApiController : ApiController
{
public IHttpActionResult MyAction()
{
var requestCount = Request.GetSessionProperty<int>("RequestCount");
Request.SetSessionProperty("RequestCount", ++requestCount);
}
}

Create Anonymous JWT token with some claims related to your scenario, Sign it with some key, Use that as in cookie (Http Only) or As bearer token. To make it little more harder further combine it with some cookies.
1)verify token signature and
2) Verify token expiry time
3) Verify Claim(skey) against cookies(skey)- no database storage required everything is in ur JWT token.

Amazon AWS and GetCallerIdentity

I'm working on an AWS project. We want to be able to issue STS temporary security credentials, with limited permissions, in order to access AWS services. We're working in .Net Core with C#.
We're using STS AssumeRoleAsync(), which is the .Net SDK's method for using the AWS AssumeRole action, to generate these credentials. The response from the call to AssumeRoleAsync() is an AssumeRoleResponse object, which is comprised in part of an AssumeRoleUser object and a Credentials object. One of the properties of AssumedRoleUser is AssumedRoleId, which is in the form of role-id:role-session-name.
We have a Lambda function which handles calling AssumeRoleAsync and returning the generated credentials in the form of a JSON object. That Lambda function is called via an API Gateway method.
All of this is working fine. The above was just to set the scene.
The next thing we want to be able to do is to use the STS temporary credentials to make other calls into AWS services. When that happens, we want be able to use GetCallerIdentity() to retrieve the AssumedRoleId for the person to whom the credentials were issued. In particular, the role-session-name is of interest to us.
So to try to accomplish this, I created another Lambda function behind another API Gateway method. I set this API Gateway method to use AWS_IAM authorization in its Method Request configuration. In its Integration Request, I configured it to Invoke with caller credentials. The Lambda function simply accepts the incoming request and calls GetCallerIdentity() and returns the result. I used the credentials returned from the previous AssumeRoleAsync() call in the request's authorization header.
Based on the information found in the docs for GetCallerIdentity and in the Principal Table to which that page refers, I expect to receive the following items in response from the GetCallerIdentity() call:
Account
Arn
UserId (this is the important bit for this discussion)
The UserId should be in the form of role-id:caller-specified-role-name, exactly the same form in which the AssumedRoleId from the call to AssumeRoleAsync was returned. That would allow me to get the caller-specified-role-name and do what we need to do with it.
But that isn't what is returned in the UserId property of the response from GetCallerIdentity().
Instead, all that the UserId property contains is the role-id — it completely omits the essential caller-specified-role-name.
Has anyone else seen this behavior? Am I overlooking something simple? Could this be a bug in the response from GetCallerIdentity?
I'm using the following Amazon SDK components and versions to make these various calls:
Amazon.Lambda.Core/1.0.0
Amazon.Lambda.Serialization.Json/1.1.0
AWSSDK.Core/3.3.14
AWSSDK.Lambda/3.3.6.2
AWSSDK.SecurityToken/3.3.1.9
Thanks for any help you can suggest!
Derek

Microsoft.Owin.Security.Oauth Bearer Token Authorization Interception

I am in the process of implementing OAuth 2 on a web API with Microsoft.Owin.Security.Oauth.
I would like to keep the bearer token small and keep private data out of it. To do this, I'd like to store a session ID in it and then fill out the ClaimsIdentity programmatically once the session ID has been received and processed. This would also give me greater flexibility related to how logging out, role changes, and other things can be handled.
This should be a matter of intercepting the right event and adding a delegate. However, I can't find an event that gets fired on my authorization provider, a subclass of "OAuthAuthorizationServerProvider". I thought that "AuthorizeEndpoint" would do it, but it does NOT get fired for API methods decorated with the [Authorize] attribute, even though these methods clearly get checked for a valid bearer token. When I overrode "MatchEndpoint", all I found is that a call to a method that was decorated with [Authorize] showed up with "IsAuthorizeEndpoint" and "IsTokenEndpoint" both set to false. The latter makes sense to me, the former does not.
I am very confused. Can somebody who knows this library tell me what's going on and what I need to do to accomplish this seemingly simple idea?

I think you may be conflating resources marked with the AuthorizeAttribute with the OWIN Authorize endpoint. The AuthorizeEndpoint and TokenEndpoint are setup in the OWIN configuration as receivers for their respective authentication types. The Authorize Endpoint is used for web-base, user-agent authentication and is where you would expect a browser to be redirected should they be unauthorized to access a resource. The token endpoint is used instead for username-password token authentication and refreshing, and is the one you want. Assuming you are assigning both of these within your OWIN startup configuration, the event you may be looking to overload for OnValidateTokenRequest to ensure that your customizations to the token do not cause it to be invalid once the client tries to utilize it again. You would want to do your actual modifications to the token at the OnTokenEndpoint event.

Send on SSO custom informations

I'm reading up on SSO with WIF STS and so on. Im ended up in this tutorial http://chris.59north.com/post/2013/04/09/Building-a-simple-custom-STS-using-VS2012-ASPNET-MVC.aspx .
I wonder how I can recive some custom data which I would like to send from the custom STS?
The Relying Party in this tutorial has no code which is evalulating the response from the STS. If I'm correct this is done by the Idendity.Model.Service.
How can I send data from the IdP and recive them in the RP? Is it also possible to send some custom information on the SSO from RP to IdP?

As per the article: "The second method, the GetOutputClaimsIdentity(), is just as simple. All that is need here, is to create a new ClaimsIdentity and add the required claims. In this case, I only set the Name and NameIdentifier claims."
So you can set any claims you want using this method - normally you would get the attributes from a repository like AD.
The RP is built using WIF so you have a bunch of built-in methods. Refer: WIF Claims Programming Model