I have the following question about Windows SSPI. I have made an Win32 app that has to authorize with a server: using protocol MS-SIPAE in NTLM mode. The app uses SSPI.
See http://msdn.microsoft.com/en-us/library/cc431510.aspx. about the MS-SIPAE. There is the following step there (http://msdn.microsoft.com/en-us/library/dd946897.aspx): “The protocol client uses an authentication protocol GSS_GetMIC() call, as specified in [MS-NLMP] section 3.1.4 for NTLM, and in [RFC2743] section 2.3.1 for Kerberos, to generate a signature token for the buffer constructed in the preceding step 2 using the authentication protocol context stored in the SA. ”
The question is: what exactly corresponds to the abstract “GSS_GetMIC” in SSPI API? In SSPI I have found a function named MakeSignature – seems this is what I need. Also an MSDN article http://msdn.microsoft.com/en-us/library/ms995331.aspx seems to confirm this. Can someone confirm this conclusion (I do not want rely on the ‘seems’ )?
Yes, GSS_GetMic is corresponding to MakeSignature. I have implemented similar thing. See this link for the full description on the details of SSPI interoperability with GSSAPI.
Related
I’m seeing a “DynDNS2” protocol referenced a lot but
I have a hard time locating its specification. AFAICS,
RFC 2136 is not versioned on the protocol level so I’m
inclined to rule that one out. Somehow I can find
numerous implementations of DynDNS2 but the repos I’ve
browsed don’t link to a canonical document either.
Example: https://support.google.com/domains/answer/6147083
– that’s Google claiming they support this protocol without
further explanation.
Where can I find the official specification of DynDNS2?
Who is in charge of its standardization and development?
The link (now) shows how to do so "manually":
https://username:password#domains.google.com/nic/update?hostname=subdomain.yourdomain.com&myip=1.2.3.4
And gives more specs.
You should check the link to the support page again and click the Using the API to update your Dynamic DNS record
Example HTTP query:
POST /nic/update?hostname=subdomain.yourdomain.com&myip=1.2.3.4 HTTP/1.1
Host: domains.google.com
Authorization: Basic base64-encoded-auth-string User-Agent: Chrome/41.0 your_email#yourdomain.com
Also you need to add the User Agent header to make sure your call is not ignored or worse, your client is blocked.
At source forge you can find a list of these dynamic DNS "protocols".
Dyn.com has quite good documentation on their site including flow diagram, update api and return codes
The RFC 2136 spec is an extension of the DNS itself and used by nsupdate command. It's complicated and is used by sysadmins.
Routers are using just a plain HTTP GET requests to some DDNS provider. Their urls are looking the same as original Dyn.com have: /nic/update?hostname=[DOMAIN]&myip=[IP].
See:
https://openwrt.org/docs/guide-user/services/ddns/client
https://sourceforge.net/p/ddclient/wiki/protocols/
We're sending REST requests from our application. The remote service will be switching off all security protocols, except for TLS1.2 soon and we need to comply. We modified our code to make sure we use TLS1.2, however we received a message from the folks running the external service that we still use an older protocol (communication with them is a little slow). We are familiar with ways to use TLS1.2 in .Net (in which our app is made), but we would like to check which protocol we actually use. Is there a public Rest service out there that we could use to check protocol used for a request?
Optionally a public Rest service that would only accept TLS1.2 would do.
So I needlessly restricted myself to looking for a rest service, which explains why I couldn't find anything (a more general question would give more google results). A similar question to mine was already asked on stack (What version of TLS does my C# program use?) and one of the answers contains this link https://www.howsmyssl.com/a/check, which is exactly what I was looking for.
Our company has an SSO app that I'm looking to replace a significant chunk of the authentication pipeline with IdentityServer4 or 3. The version I'm replacing has its own custom implementation of Dynamic Client Registration (not to spec) and a UI to manage it.
There are a number of Github issues across the IdentityServer project discussing the issue and the resolution appears to be that it hasn't been implemented and someone looking to use DCR should write their own implementation of the spec as an extension.
Am I correct that this is currently not possible and I would be better served creating my own DCR extension on Github for IdentityServer? Or have I missed something with my Google-fu and someone's already written an extension?
Note I'm happy to implement my own if it's necessary.
IdentityServer 4 does not provide any implementation of dynamic client registration as they consider it out of scope for the project.
However you can implement your own, either as a middleware or as a MVC controller.
You need an endpoint that uses ConfigurationDbContext to the Clients table.
Source code for this is a issue on GitHub.
https://github.com/IdentityServer/IdentityServer4/issues/1248
IdentityServer itself (the STS) has no implementation of OIDC DCR
https://openid.net/specs/openid-connect-registration-1_0.html
This is more of an admin type functionality.
The Azure AD team has a sample which authenticates against the AAD common endpoint and uses the returned claims to automatically provision new tenants. It might be a good place to start...
In owasp 2014 (https://www.owasp.org/images/5/58/OWASP_ASVS_Version_2.pdf) we have:
V 11.2 (page 31): Verify that the application accepts only a defined
set of HTTP request methods, such as GET and POST and unused methods
are explicitly blocked.
Does it mean we cannot use non-standard HTTP methods? If yes, can we say that WebDAV doesn't conform to OWASP ASVS standard? If the answer is no, is there any formal document, blog post or a FAQ for this?
The way I read this is that as long as you define which request methods you accept and block everything else you can use any method you want.
only a defined set
is not the same as you cannot use none standard, it say that for instance if you are not using POST you should explicitly block POST
such as GET and POST
here GET and POST are examples of methods, not a complete list of available methods.
So use the methods that fits with your needs, but verify that the application do not accept any request not in the list of acceptable requests
The quick answer is NO! I asked Andrew van der Stock the Owasp ASVS project leader. This is my question:
Dear Owasp Asvs project leaders (Daniel & Vanderaj),
I want to know if OWASP ASVS 2014 Level 1 force us to use just
standardized Http Methods(GET,HEAD,POST,PUT,
DELETE,CONNECT,OPTIONS,TRACE) or we can use non-standardized Http
methods too? (by listing them in a document like what
WebDav(https://en.wikipedia. org/wiki/WebDAV) did)
With Respect
And he replied me:
I think the primary driver is not to worry about which methods are
available, but if they are necessary and safely configured.
Essentially, we are asking for: All methods are denied by default,
except for: A positive set of allowed methods, AND all these methods
are correctly and securely configured
For example, OPTIONS and HEAD are required by Chrome doing pre-flight
CORS checks on AngularJS and other apps, and many apps require PUT and
DELETE. Therefore these methods are necessary. If you use a new
method, such as "EXAMPLE", the idea is that you don't also accept any
other words, such as "RIDICULOUS", and "EXAMPLE" is correctly
configured to be safe.
So if WebDAV is also enabled for whatever reason, it's important to
make sure that it is properly secured. There may be a solid reason for
it to exist (e.g. SharePoint), but to allow anonymous users to
overwrite your site or change things is not okay.
thanks, Andrew
As the title says. Alamofire is an HTTP networking library written in Swift. But I want to know if it works over https network?
And is there any other library in swift for accessing an api and parse a json file?
As described in the official Alamofire document you can work also with HTTPS protocols but remember to enable NSAppTransportSecurity as described here (Stack Overflow answer)
P.S.: now there is the 3.4.0 version available, there is only one issue about SSL connections, you can find here
DETAILS:
As CouchDeveloper commented in this post , you must remember that with this configuration you actually bypass "App Transport Security", so you can control your white/black domains list in this dictionary by the NSExceptionDomains as documented in the Apple pages or in this useful page that discuss about "Working with Apple’s App Transport Security". This documentation explain how to restrict the app network access to handle the app security settings.