Which Identity does CodeFluent.Runtime.CodeFluentUser.Current use?
Does it use HttpContext.Current.User.Identity or Thread.CurrentPrincipal.Identity?
Or does it use a fallback mechanism?
CodeFluentUser.Current calls CodeFluentUser.Get(CodeFluentUserIdentityType.CurrentOrWindows). If you use CodeFluentContext.User, the identity type can be set in the configuration file (by default userIdentityType="AspNetOrWindows")
Here's the documentation for each CodeFluentUserIdentityType:
Windows: WindowsIdentity.GetCurrent()
AspNet: HttpContext.Current.User when http context is available; CodeFluentUserIdentityType.Windows otherwise
AspNetOrWindows: HttpContext.Current.User when http context is available and user is authenticated; CodeFluentUserIdentityType.Windows otherwise
Current: Thread.CurrentPrincipal.Identity
CurrentOrWindows: Thread.CurrentPrincipal.Identity when authenticated; CodeFluentUserIdentityType.Windows otherwise
According to your answer AspNet means:
HttpContext.Current.User when http context is available; CodeFluentUserIdentityType.Windows otherwise
However, according to the documentation AspNet means:
If the context is ASP.NET, HttpContext.Current.User.Identity will be
used. Otherwise, Thread.CurrentPrincipal.Identity will be used.
I assume the documentation is right about this?
Related
can different transport(shmem, tcp) bind to different datawriter/datareader in one publisher/subscriber in OpenDDS?
I'm not sure OpenDDS supports this way with RepoInfo Discovery or only in Static Discovery?
I use
`
TheTransportRegistry->bind_config("tcp1", datawriter1);
TheTransportRegistry->bind_config("shmem1", datawriter2);
`
but it seems not work. still use the publisher‘s transport config
Yes, it should be possible, but it needs a bit more setup. After they are created writers and readers (as well as any DDS::Entity) have an enable function that has to be called before they can be used. By default this is called automatically by create_datawriter and create_datareader. This is important because readers and writers can't change their config after they're enabled. You have to disable the autoenable_created_entities property in parent entity's QoS, create the reader or writer, call bin_config, and finally call enable manually. Section 3.2.16 of the OpenDDS Developer's Guide talks a bit about this, but doesn't have an example, so here's snippet that I tested with the error checks and unrelated args omitted:
DDS::PublisherQos pub_qos;
participant->get_default_publisher_qos(pub_qos);
pub_qos.entity_factory.autoenable_created_entities = false;
DDS::Publisher_var publisher =
participant->create_publisher(pub_qos, /*...*/);
DDS::DataWriter_var datawriter1 = publisher->create_datawriter(/*...*/);
TheTransportRegistry->bind_config("tcp1", datawriter1);
datawriter1->enable();
You can also set this QoS on the domain participant or the service participant instead of the publisher or subscriber, but that requires manually enabling all the entities, which includes the publishers, subscribers, and topics, so I'm not sure I recommend that.
Our identity server uses identity server 3 and implements sustainsys.saml2 for SAML integration. We have made an effort to move from v1 to v2 of the SustainSys.Saml2 NuGets. With v1, we explicitly set our audience restrictions by doing:
_spOptions.SystemIdentityModelIdentityConfiguration.AudienceRestriction = new AudienceRestriction
{
AllowedAudienceUris =
{
_audience,
new Uri(_entityId),
},
};
However, in v2.9.0 the SpOptions.SystemIdentityModelIdentityConfiguration property is no longer accessible.
Is there no longer a need to set the audience restriction? Or is there a different way to set it?
I'm not seeing anything in the docs... hopefully I'm not just blindly missing it.
v2 doesn't use System.IdentityModel, but instead the more modern Microsoft.IdentityModel nuget packages. The corresponding settings are now found in SpOptions.TokenValidationParametersTemplate.
Some parameters,like the audience restriction is set after the template is copied, but you can alter the values in the Unsafe.TokenValidationParametersCreated notification. The reason it is under "Unsafe" is because setting the wrong values in the TokenValidationParameters could remove important security checks.
When I create a resource/method in AWS API Gateway API I can create one of the following methods: DELETE, GET, HEAD, OPTIONS, PATCH or POST.
If I choose GET then API Gateway doesn't pass authentication details; but for POST it does.
For GET should I be adding the cognito credentials to the URL of my GET? or just never use GET and use POST for all authenticated calls?
My set-up in API Gateway/Lambda:
I created a Resource and two methods: GET and POST
Under Authorization Settings I set Authorization to AWS_AIM
For this example there is no Request Model
Under Method Execution I set Integration type to Lambda Function and I check Invoke with caller credentials (I also set Lambda Region and Lambda Function)
I leave Credentials cache unchecked.
For Body Mapping Templates, I set Content-Type to `application/json' and the Mapping Template to
{ "identity" : "$input.params('identity')"}
In my Python Lambda function:
def lambda_handler(event, context):
print context.identity
print context.identity.cognito_identity_id
return True
Running the Python function:
For the GET context.identity is None
For the POST context.identity has a value and context.identity.cognito_identity_id has the correct value.
As mentioned in comments: all HTTP methods support authentication. If the method is configured to require authentication, authentication results should be included in the context for you to access via mapping templates to pass down stream as contextual information.
If this is not working for you, please update your question to reflect:
How your API methods are configured.
What your mapping template is.
What results you see in testing.
UPDATE
The code in your lambda function is checking the context of the Lambda function, not the value from API Gateway. To access the value passed in from API Gateway, you would need to use event.identity not context.identity.
This would only half solve your problem as you are not using the correct value to access the identity in API gateway. That would be $context.identity.cognitoIdentityId (assuming you are using Amazon Cognito auth). Please see the mapping template reference for a full guide of supported variables.
Finally, you may want to consider using the template referenced in this question.
if you have a REST API that is hypermedia-driven (HATEOAS) you can easily change a client's behavior by including or omitting links in the response (_links). That enables a client to completely forget about testing permissions for the operations that are possible in the current state of a resource (the link to the operation is present or not).
Additionally you can leave out properties in the response if the current user doesn't have permission to see it.
That way authorization is done entirely on the server (and controls actions and properties that are eligible to execute/view).
But what if I want to a have a read-only property? It is no problem for the REST API to ignore the property if it is present in the request (_POST_ OR _PUT_). it just won't get saved. But how can a client distinguish between write and read-only properties to present the user appropriate controls (like a disabled input field in HTML)?
The goal is to never ever have the client request a user's permissions, but to have a completely resource driven client/frontend.
Any help is greatly appreciated :-)
If I misunderstood your question, I apologize upfront. With that being said...
But how can a client distinguish between write and read-only
properties to present the user appropriate controls (like a disabled
input field in HTML)
Well, there are multiple solutions to this. The simplest one I can personally think of is to make each property an object having a simple structure of something like:
...
someProperty: {
value: 'some value',
access: 'read-only'
},
someOtherProperty: {
value: 'some value',
access: 'write'
}
...
You can obviously get as creative as you want with how you represent the "access" level of the property (using enums, booleans, changing access to be isReadOnly or whatever).
After that, the person using the API now knows they are read-only or not. If they submit a "write" value for a "read-only" property as part of the POST payload, then they should expect nothing less than a 403 response.
Edit:
In case you can't alter the properties in this manner, there are a number of other ways you can still achieve this:
write documentation that explains what access each property has
create a route that the user can submit 1 or more properties to in order to receive a response that indicates the access level of each property (response: { propName: 'read-only', propName2: 'write', etc.)
Return a propertyAccess map as part of the response (mapping properties to access levels).
end of the day, you just need a way to map a property with an access level. however that's done depends on what your restrictions and requirements are for the api, what changes you can make, and what is acceptable to both your client(s) and the business requirements.
Using the code here shows how to add a column:
http://fiddler2.com/documentation/KnowledgeBase/FiddlerScript/AddColumns
What I'd like to know, though, is the ip (or name) of the client issuing the request. Is that possible to determine?
Thanks,
Ben
I believe you can grab this off Session object that is passed in. So in the code example in the article you link to you would set the value of you column to oS.clientIP.
For convenience the complete code you have to insert into the Handlers class:
public static BindUIColumn("ClientIP")
function ColClientIP(oS: Session){
return oS.clientIP;
}
This is now available from the UI using Customise Columns and the session flag X-clientIP. Now means V5.0.20211 of Fiddler Classic. Probably been there for some time.