IdentityModelEventSource has a property called ShowPII that means that Personally Identifiable Information will be added to the logs (in relation to security). This value is used to decide when to log some OAuth2 sensitive data.
I am trying to understand what kind of Personally Identifiable Information will be logged:
Client ID? (aka Client Key, Consumer Key)
Client Secret? (aka Consumer Secret)
Json Web Tokens? (aka JWT)
Access Tokens?
Refresh Tokens?
Kerberos Tickets?
PKCE Values?
Authorization Codes?
I know it cannot get access to usernames and passwords because they are only exchanged directly with the IDP.
But but I need to know if I need to find a way to lock down my log files because it will have data that constitutes a security vulnerability.
This is possible log messages of IdentityModel: LogMessages.cs
About
I am trying to understand what kind of Personally Identifiable Information will be logged
I won't copy-paste log messages from there (especially, as they can change at any moment). You can check them yourself and decide what should be considered as the PII.
But here's an interesting example:
"IDX10615: Encryption failed. No support for: Algorithm: '{0}', SecurityKey: '{1}'."
and this is how it's used:
throw LogHelper.LogExceptionMessage(new SecurityTokenEncryptionFailedException(LogHelper.FormatInvariant(TokenLogMessages.IDX10615, encryptingCredentials.Enc, encryptingCredentials.Key)));
If you'll follow the track you'll find out that encryptingCredentials.Key will be logged if ShowPII = true and won't be logged if ShowPII = false.
Of course, depending on your use case, this particular message may never appear in your logs. And not all messages so outrageously leaky. But you never know:
your use case may change
you may be mistaken about the set of messages IdentityModel can emit for your use case
IdentityModel code may change, and you may forget to check if messages' set is still secure
So about
if I need to find a way to lock down my log files
Yes, you definitely need to.
Or better yet - don't use ShowPII = true in production for monitoring, use it only in development environment for debugging purposes.
Looking at the source, it appears that when ShowPII is on - it will do two things:
Replace all parameters passed to library-specific exceptions with their data type names
For all system exceptions - replace inner message with exception type name
In this context "library-specific" is an exception that is of type Exception and its full type name starts with "Microsoft.IdentityModel." (library defines a few)
Depending on your use case you'd see a variety of parameters that can be logged with custom exceptions. A quick search for FormatInvariant yields quite a few for your consideration.
Again, depending on how you use it, you might get a better idea of what the error messages are by looking through relevant LogMessages.cs file on your specific namespace.
P.S.: on a side note, it appears that default ShowPII setting is GDPR-compliant
Related
I could not find in the docs the canonical way to check whether given credentials can be used to clone given repository. There is an issue that suggests that one way may be to check whether git_cred_acquire_cb() is called more than once. Can somebody confirm this or point out another way?
This is the suggested way. If your credential callback is called a second time, then the first credentials that you provided were not accepted. This pattern is primarily useful for UI applications (popping up a modal username/password dialog).
You can use the callback data to count the number of times you were called.
I realize that this may be imperfect, especially if you're binding libgit2 in another language. Setting up a data struct on the heap and managing its lifecycle is not always trivial.
You may also be able to just provide credentials and wait for a GIT_EAUTH return code. In theory, the various transport mechanisms should give up after several authentication failures no matter what. However, we found at least one bug in the 0.27 releases that would loop forever. Hence the suggestion.
I have my text validation messages in a properties file. How would you consider getting the message from the key? A domain service interface implemented by the infraestructure? Or would the implementation live in the domain too?
In the red book, text messages are literal, when passed to exceptions for example. They belong to domain.
But what if we deal with keys of a messages.properties file? How would you do it?
Thank you.
It is unlikely that the messages are part of the domain itself. Think about who will drive the changes to the messages. Will it be domain experts or marketing/UX people indicating that the particular message should be altered to convey the meaning better to customers?
If you had to create, for example, a new B2B client, do you anticipate that some messages would have to be changed? Does it mean that the domain has changed?
I would advise keeping the exceptions in the domain as independent from the external representation as possible. So, instead of saying throw new PaymentProcessingException("Insufficient funds") consider throw new InsufficientFundsPaymentProcessingException(). Then you could translate the specific exception into a proper message using the infrastructure service at the representational edge of your application.
I had the same problem: at the end I've used a mixture of answer from Oleg and message keys.
What I've done are custom exceptions (DomainException) where I've added a custom field with the key of the message (at the end they're domain exceptions, they could/must be customized). Every exception has its own value. Where I handle the exception I just add the code as a message response. Somewhere later, where the response is handled, I ask a service to translate the key.
Suggestions are welcome if this reveals not as good as it looks (for me).
Recently I've been into multiple arguments on whether to throw an exception on false User Input.
Example: I'm trying to login though my account is not activated. As the programmer in an OO-language, I could handle this in a few ways. For this case, lets stick to these two:
Throw a custom Exception from the local Service with a representative way, extending Exception. Catching this in the class handling User Input.
Use a Validator to call the local Service to check whether this account is logged in.
My vision, like many others, an Exception represents a fault in the program. E.g. database unreachable, error in parsing data.
Vision of many others as well, the case of logging in without being activated is not a succesful scenario on any use case and will thus fail. This shouldn't not happen and is worth throwing an Exception for.
Personally, I would handle this kind of problem with a Validator, sticking to Exceptions for just the faults in the program. However though, I would like to get a constructive answer on which case is preferred. If possible, referring to any documentation. I'm using Java, though this problem is not restricted to any language (as long as it's OO I guess).
In case of a validation error, the flow of your application must be interrupted. For example, you must terminate a singing up progress if an invalid mail address supplied. Thus, the exceptions can be used for the purpose of user input validation.
As an example use, you can check JSF. It benefits from exception mechanism of Java to handle user input validations. The following links can be useful:
http://www.mkyong.com/jsf2/custom-validator-in-jsf-2-0/
http://www.ibm.com/developerworks/library/j-jsf3/
I am developing iOS application running against a remote server, having another developer behind it. The project and an API draft we are writing are in initial phase.
The problem we are faced with is that we are not satisfied with existing amount of conventional status codes described by HTTP/REST specifications: there are cases where we are uncertain about what code to pick up.
Examples to provide minimal context:
Server-side validation errors. Fx. Client-side validations are ok, but server API has recently been changed slightly, so a server should return something indicating that it is exactly the validation problem.
An attempt to register user that already exists. SO topics do not provide any precise point on that.
A user is registered, and tries to log in without having the password confirmation procedure accomplished.
Two obvious approaches we see here:
Use fx 400 error for the cases when an appropriate conventional status code could not be found. This will lead us to parsing error text messages from JSON responses. Obviously, this approach will introduce superfluous complication in a client-side code.
Create our own sub-codes system and rely on it in our code. This one involves too much artificial conventions, which will lead us towards becoming too opinionated and arbitrary.
Feeling that the number of such cases is going to grow, we are thinking about an introduction of custom sub-codes in JSON responses our server should give (i.e. choose the second approach).
What I'm asking here:
What are the recommended approaches, strategies, even glues or hacks for these kinds of situations?
What are pros-cons of moving away from strictly following REST/HTTP conventions for status codes?
Thanks!
For validation problems, I use 422 Unprocessable Entity (WebDAV; RFC 4918)
The request was well-formed but was unable to be followed due to semantic errors. This is because the request did not fail because of malformed syntax, but because of semantics.
Then in order to communicate you just need to decide on your errors format, so for situation 1 if there is a required field you might return a 422 with the following.
{
"field": ["required"]
}
I would treat number two as a validation problem, since really it is a validation problem on username, so a 422 with the following.
{
"username": ["conflict"]
}
Number three I would treat as a 403 Forbidden because passing an authorization header will not help and will be forbidden until they do something other than pass credentials.
You could do something like oauth2 does and return a human readable description, a constant that people can code against that further clarifies the error and a uri for more information.
{
"error": "unfinished_registration",
"error_description": "Must finish the user registration process",
"error_uri": "http://yourdocumentation.com"
}
Note: you will find that people disagree on what http codes map to what situation and if 422 should be used since is part of the WebDAV extensions, and that is fine, the most important thing you can do is document what the codes mean and be consistent rather than being perfect with what they mean.
There's no such thing as "sub-codes" in HTTP (Microsoft IIS is clearly violating the spec, and should be flogged).
If there's an appropriate status code, use it; don't say "this status code means that in my application" because that's losing the value of generic status codes; you might as well design your own protocol.
After that, if you need to refine the semantics of the status code, use headers and/or the body.
For the use cases you have described, you could use these error codes:
1) 400 Bad Request
The request could not be understood by the server due to malformed syntax. The client SHOULD NOT repeat the request without modifications.
2) 409 Conflict
The request could not be completed due to a conflict with the current state of the resource. This code is only allowed in situations where it is expected that the user might be able to resolve the conflict and resubmit the request. The response body SHOULD include enough
information for the user to recognize the source of the conflict. Ideally, the response entity would include enough information for the user or user agent to fix the problem; however, that might not be possible and is not required.
Conflicts are most likely to occur in response to a PUT request. For example, if versioning were being used and the entity being PUT included changes to a resource which conflict with those made by an earlier (third-party) request, the server might use the 409 response to indicate that it can't complete the request. In this case, the response entity would likely contain a list of the differences between the two versions in a format defined by the response Content-Type.
3) 401 Not Authorized
The request requires user authentication. The response MUST include a WWW-Authenticate header field (section 14.47) containing a challenge applicable to the requested resource. The client MAY repeat the request with a suitable Authorization header field (section 14.8). If the request already included Authorization credentials, then the 401 response indicates that authorization has been refused for those credentials. If the 401 response contains the same challenge as the prior response, and the user agent has already attempted authentication at least once, then the user SHOULD be presented the entity that was given in the response, since that entity might include relevant diagnostic information. HTTP access authentication is explained in "HTTP Authentication: Basic and Digest Access Authentication" [43].
For any other use case that you have, it varies. I would probably go with number 2 if there is truly no standard way of encoding specific errors.
string Authenticate(string username, string password);
Give a simple authenticate method that takes in a username and password and returns a token if successful, I need to be able cope cope with various failure situations including - invalid credentials, locked account, awaiting verification etc.
What is the best way to go about this?
I was thinking about either of the two options below but am open to anything else:
(1) changing response to an object with an enum as well as the token. A bit worried with regard to versioning with this method though.
(2) faultcontracts for each of the failure cases. Not sure about performance here though.
You should use the FaultContract only when you want return more details/manage an exception on the client side. An exception (as you guess by the name itself) is something you couldn't foresee or rather something that happen against your will :-)
In your case you already know the login can be locked, invalid etc. I think you should return an enumerator (or encapsulate it into an object) to provide more information about instead of raise an exception to force to use fault contract
I hope it makes sense