I want to download a file using BITS or any other asynchronous file download winapi. Can anyone suggest any method to identify the proxy authentication scheme on server so that I can act accordingly in my application. (For ex. either its NTLM or Kerberos or simple Basic Authentication, Digest Authentication or Passport ... etc. )
Related
I am trying to understand the purpose(s) of client secrets. Is it to prevent someone from creating a fake server that pretends to be my server? If not, what is it? And does it protect against anything else?
The client secret is used to identify the application that requires an access token in order to access a resource on behalf of the user. Only clients registered in the authentication service can request access. Not only will user authentication be necessary, the client application must also be legitimate. Otherwise someone could impersonate the client application.
This type of client authorization should only be used by confidential clients ([OAuth2 Client Types][2]).
confidential
Clients capable of maintaining the confidentiality of their
credentials (e.g., client implemented on a secure server with
restricted access to the client credentials), or capable of secure
client authentication using other means.
public
Clients incapable of maintaining the confidentiality of their
credentials (e.g., clients executing on the device used by the
resource owner, such as an installed native application or a web
browser-based application), and incapable of secure client
authentication via any other means.
When using flows with clients that cannot guarantee the confidentiality of this secret (i.e. implicit), the identity of the client cannot be verified. In those cases it can be verified by means of the redirection URI. As an additional measure, it should limit the exposure of refresh tokens.
Officially it is no longer recommended to use the implicit flow for security reasons, the recommendation for this type of clients is Authorization Code + PKCE extension. [See OBBA document][1]
For authorizing users within a browser-based application, the best current practice is to
o Use the OAuth 2.0 authorization code flow with the PKCE
extension
o Require the OAuth 2.0 state parameter
o Recommend exact matching of redirect URIs, and require the
hostname of the redirect URI match the hostname of the URL the app
was served from
o Do not return access tokens in the front channel
[1]: https://datatracker.ietf.org/doc/html/draft-parecki-oauth-browser-based-apps-02)
[2]: https://www.rfc-editor.org/rfc/rfc6749#section-2.1
Sometimes you have some ApiResources which called by Clients and there is no any user in the flow. for example fetch instagram's post using instagram's api. now instagram wants to control client behavior so client should be authorized for instagram befor any api call. in this situation you need define some secret for each client to identify them.
This an example of client's secret usage.
In previous versions of ASP.NET you got authorization and authentication out of the box from the default template.
I have a Web API application and three or four well defined clients that will consume it and I need to secure it.
I read about OpenID and OAuth but they seem like an overkill for my problem.
What's the simplest way to achieve that?
These would be the 3 best solutions if you require security:
WEB API browser client: Implicit OAuth 2 flow
WEB API Application client: OAuth2 code flow
(With OpenId)
OR: Cookie Authentication with Cross-site request forgery protection. (Default template MVC 6 website template)
If your application is public, I would use at least one of these, otherwise it depends on how secure your data must be.
Well, it depends on your scenario. If you don't need authentication (because it's a server-to-server scenario), use a security token as described below. If you need authentication of the user, you may use Basic or Digest security combined with HTTPS.
In a security token scenario, the client simply has to add the token to the request headers and the server needs to validate the token. Make sure the requests transit as HTTPS to make sure the token is encrypted. Remember, this method is only valid if you know the applications that will access your API will be in a secure environment (another server, for example). Otherwise, I would go for another solution.
I am trying to setup Burp Suite so I can be tamper with HTTP requests and run security vulnerability scans against a .NET application that uses Kerberos for authentication(i.e. windows integrated authentication w/Kerberos support only). To access the app normally in IE, I add a set of credentials to Windows using Credential Manager, which then uses the credentials during authentication. I setup Burp Suite and can see requests/responses they pass through from the browser, however I cannot tamper with requests in Repeater/Scanner because Burp Suite does not update the Authorization header automatically.
I know Fiddler supports Kerberos, so my thought was to chain Burp to Fiddler. I first made sure I could get tampering to work in Fiddler (using this link as a guide). I then set Fiddler to be Burp's upstream proxy, but when I tampered with a request in Burp I still got a 401 Unauthorized when issuing requests.
Any other ideas on how I could get Burp to do Kerberos Authentication?
If you use Fiddler's Rules > Automatically Authenticate menu option, Fiddler will automatically respond to HTTP/401 login challenges using NTLM, Digest, or Negotiate (Kerberos) using the current user's login credentials.
If the login credentials for the site are different, you need to do this:
Rules > Customize Rules. Scroll to the OnBeforeRequest method. Add the following:
if (oSession.HostnameIs("targetsite.com"))
{
// Don't forget to use a double \\ in the string below
oSession["X-AutoAuth"] = "domain\\user:password";
}
Fiddler will use the specified domain\user and password to respond to HTTP/401s from targetsite.com.
I have a setup with Tivoli Access Manager (TAM) as reverse proxy for some application servers on the backend side. TAM is responsible for authenticating users. Is it possible to access the credentials a user passed in during TAM authentication in the backend applications?
I need this because the backend applications connect to a Host-System and there the credentials are needed to log in.
there are a couple of options you might have for this :
Since you mention TAM, I guess you are still using 6.X, so you can use a custom CDAS (Cross-domain Authentication Service) library. You would need to implement the library yourself in C and handle the authentication part and return the clear text password as an extended entitlement in the credential. This will allow you to add this extended entitlement as an injected HTTP header for the junctions that require the password. You can get more information here : http://www-01.ibm.com/support/knowledgecenter/SSPREK_6.1.0/com.ibm.itame.doc_6.1/am61_web_devref58.htm%23chap-wsd-write-custom
You can implement your own External Authentication Interface. EAIs are external web applications where WebSEAL can delegate the authentication part. In that EAI, as in CDAS, you would have to handle the authentication part yourself - probably against TAM user registry - and then return the clear text password as an extended attribute in the credential to be used as a custom HTTP header for the junction that requires it. See http://www-01.ibm.com/support/knowledgecenter/SSPREK_6.1.0/com.ibm.itame.doc_6.1/am61_web_devref128.htm%23appx-wsd-eai
Leverage Tivoli Federated Identity Manager and a custom STS chain to do the authentication and return the clear text password as part of the credential.
For all 3 of the above options, you would need to modify the existing backend application to read the injected HTTP header and use the clear text password to perform the actions to the Host.
I have done all 3 for various integrations and I think your best choice is writing an EAI, as CDAS got deprecated with ISAM 7 and the 3rd option requires an additional software component.
I'm currently working on building a WCF web Service, I was asked to use Basic Authentication over HTTPS and also to validate whether the user is present in an LDAP group for Authorization.
I searched in Internet and it is said that Active Directory Authentication is not available in IIS and we should use our own Custom Basic Authentication Module or UserNamePasswordValidator.
Link I used for coding Custom Authentication Module
I have hosted the WCF in local IIS with SSL and now it is running under https.
The question is, If I implement this one, I need to add the Authorization header manually it seems. Is there any other way I can get the User Name or Password entered in the Basic Authentication dialog which is showed when we open the service in a browser ?.
OR
could you please provide an advice on what are the things I need to do to implement the above said Security ?
I'm helpless and requesting your help on this !!!!. Thanks in Advance.
Background:
I also tried UserNamePasswordValidator, but it was doing at the Application level, I was able to view the wsdl file (Meta data of the web service without even providing credentials) so I did went with the Custom Basic Authentication Module.
With Custom Basic Authentication Module , it is asking for credentials before the svc is opened in browser. So I think this would best suite. Please provide your valuable suggestions.
Basic authentication works by the web server returning a 401.0 status code AND a WWW-Authenticate response header with the value 'Basic real="xxx"' where the realm is simply information shown to the user so that they understand what is asking for the authentication. When the browser receives this type of response, it displays a dialogue box to the user asking for a username/password. The browser then re-submits the originally requested URL, but also includes an 'Authorization' header whose value is a base64 encoded string which includes the username and password.
A custom authentication module for IIS basically has to handle this interaction. For each request that comes in, it needs to see if there is an 'Authorization' header, and if so, it extracts the username/password, authenticates them in whatever fashion it likes, and if successful sets up the Context.User. If there is no 'Authorization' header, or the username/password are not valid, then the module must set the response code to 401.0, and ensure that there is a WWW-Authenticate header (as described above).
In order to use the module, all other authentication modules in IIS must be disabled (although there seem to be some circumstances in which the anonymous authentication module should be enabled). Due to caching in IIS, don't be surprised if not all requests are passed to your authentication module.