I need to support DoD issued CAC-based authentication in my web application deployed in JBoss. Could someone give me pointers on where to start, the steps involved, etc?
Also, which JCE provider should I go with (OpenSSO, BountyCastle, etc)? I tried to google for a list of (active/current) providers but couldn't really find it. Is there a list of JCE providers that are most popular (by virtue of their underlying security algorithms? Thanks.
I haven't worked with CAC cards, but PKI integration is typically handled by PKCS#11 middleware installed on the client CPU. On the server, you may need to intercept the request at the apache module level to enable PKI/SSO, here's a slideshow with more info on how they did it for forge.mil:
http://www.slideshare.net/rbulling/enabling-web-apps-for-dod-security-via-pkicac-enablement-forgemil-case-study
If you need to do other web based interactions with the card (non PKCS11 functions like if you want to talk to one of the other apps installed on the card from your web app, or install an applet on the card) you'll need some kind of browser plug-in to send raw APDUs or higher level commands via PCSC. My company makes a plug-in for this purpose, it's available at https://cardboss.cometway.com.
Finally, I like bouncycastle... I doubt you will find any lists of JCE providers sorted by popularity.
Related
I have a product which consists of internal ASP.NET/MVC web sites all using WIF to enable SSO through a custom STS/IdP service. We now have a new partner site hosted outside our network on another domain and would like to enable SSO for users as they navigate between the sites. The new site uses different technologies (e.g. python) but we assume we can create a trust relationship using SAML standards as the protocol.
With SAML as the underlying protocol we assume this can be achieved but we cannot find any guidance on patterns for implementation, best practice guidance, etc... Can some recommend some resources on how to establish this type of cross-domain trust?
Note: While other options like OAuth could address this, we would prefer to stick with a SAML-based solution
Does your custom STS/IdP service support SAML?
On the python side, they will need a SAML stack. There's a number around - refer Introduction to OneLogin's SAML Toolkits e.g. There's a good diagram there as well that shows the login flow.
Then you need to get the python SAML metadata and give them your custom STS/IdP SAML metadata.
Import on both sides, configure whatever assertions you need and you should be good to go.
You'll also need to sort out the signing certificates that go into the metadata.
Example of process using simpleSAMLPHP - Configuring the SP
Following provides excellent example of SAML implementation:
http://www.codeproject.com/Articles/56640/Performing-a-SAML-Post-with-C
We used it in our project and it worked fine.
I have a web role project in ASP.NET made for Azure deployment and need to have authentication.
I have to choose between Office 365 and On-Premise Active Directory.
Looks like both needs to be integrated to Azure Active Directory using Access Control Service.
What are the pros and cons of both?
Also if there are any other possibilities.
As astaykov mentions in his comment on your question you are not restricted to involving Access Control Services in this scenario. Not sure why he didn't submit that comment as an answer.
If you truly must go against your Office 365 or On Premise AD then what you are really saying asking is what is the difference between the two. I'll list some thoughts, but first if you want to implement these then here are some links:
Offerings from MS on Identity: http://msdn.microsoft.com/en-us/security/aa570351.aspx
Using ADFS V2 in your Azure Deployment:
http://channel9.msdn.com/shows/Identity/WIF-Workshop-9-WIF-and-Windows-Azure/ This is a little older material and I couldn't find much on using WIF to connect directo ADFS V2 that was more current. You do NOT have to invovle ACS in this at all. Sadly, this was misunderstood a lot when ACS was released.
Using Office 365/Windows Azure AD: http://msdn.microsoft.com/library/windowsazure/dn151790.aspx
Note: I have connected Web sites running in Azure to ADFSV2 directly, but I've not had a chance to work with the WAAD/Office 365 stuff yet.
If you choose to go with exposing your AD on premise then you would likely do this by exposing it using ADFS V2. This is what opens up the endpoint for the code running WIndows Identify Foundation (WIF) objects to reach out and deal with authentication. The upshot of this is that you don't have to worry about Office 365 logins or a WAAD separately and might be an interesting choice if you don't have those services for ANY OTHER reason but this one scenario. The down side is that you are exposing a proxy to your AD on an endpoint at your own location. If you lose connectivity to the internet then no one attempting to use the apps in the cloud would be able to authenticate. This is also the option I might look at if the users of the app in the cloud will ONLY EVER access it while behind your firewall (such as being at an office or even over VPN). This is because you can set it up so that your app uses a ADFS endpoint that is NOT exposed to the internet, but if they are behind your firewall it would still work. This pretty much ensures that only people already behind your firewall can use your app.
If you choose to use Office 365/WAAD integration then the upside is that you can sync with your onpremise AD to give single sign on to resources on your network as well as to the apps in the cloud. You also make access to your cloud apps more resilient because they have no need to depend on your exposed ADFS V2 endpoint. If you use Office 365/WAAD for any other reason (such as your employess use Office 365 for email, collaboration, etc.) then this is the option I would look at first.
You should look at ACS if you want to integrate with other identify providers such as Google, Facebook or even other companies. Technically you wouldn't have to use ACS at that time either, but it will certainly save you a ton of work to use ACS and not write the integration code on your own for each provider.
In investigating federated authentication, I've been running into a protocol alongside SAML: HTTP-FED.
Curiously, I can't find any technical documentation for this protocol.
What is it? Is it, like I suspect, a claims-based protocol for use with HTTP instead of WS- services?
HTTP-Fed appears to be a creation of a commercial vendor (Symplified). It has not been ratified by any standards bodies (that I've found) which is why you probably can't find much on it. From what I've read on their website, it appears to essentially be a fancy name for credential caching/credential replay across the internet. From their site -- http://www.symplified.com/http-federation/
"... HTTP-FED leverages the existing HTTP login mechanism at the SP.
The implication of this is that no changes to the SP (destination
application) are required and no special software is needed by SPs,
thereby reducing the effort required to federate domains."
It's not a standard so there's no info on how you'd implement it outside of buying their product. If you're looking at Web SSO for Cloud Applications, I'd stick with actual standards (SAML, OpenID, OAuth, Open ID Connect) that are designed with security in mind for this type of activity.
I have a bit of a difficult situation in that I need a way for a client connected to an ASP.NET MVC site to sign and decrypt blobs with their private key, such that the server never sees the private key material. In the decryption case, these are encrypted session keys. It is acceptable that the server see the session key, just not the users private key.
That is, I need to present the user some content in a browser, have some javascript (or java applets, or silverlight, etc.) execute client side that communicates with a hardware token on the client, and returns the result to the server.
This is NOT client side authentication. I don't need to simply authenticate via IIS with a certificate. The hardware tokens are HID OmniKey USB readers.
My understanding of the options available are:
1. Mozilla Javascript Crypto - This seems to be the optimal route. It appears that Firefox exposes various smart card events and functionality to remote sites. I see how to sign text, but nothing about decrypting blobs (the largest goal). There seems to be methods for loading a PKCS#11 module, but the documentation seems to stop after that.
2. Silverlight with Elevated Trust - This is my second preferable route, because of familiarity with Silverlight and .NET. Silverlight 5 has the ability to P/Invoke, so I could always call the PC/SC modules, but this requires running Out of Browser, which I can't do. There seems to be some posts about running a Silverlight app In Browser with elevated trust, but this is a global setting, and so I don't want to diminish security for other applications.
3. ActiveX - An ActiveX component can interact with the PC/SC module, but this would be an Internet Explorer only solution. If forced to pick a required browser, I'd prefer Firefox or Chrome.
3. Firefox/Chrome Extension - My understanding is Firefox XPCOM is C++, and I can just directly call the PC/SC libraries, and the extension can interact with scripts/DOM on the remote site. I'm not sure how the remote site though can trigger a Firefox extension. In other words, how does the remote site tell the extension "ok, it's time to sign"? One such example of this route is XSign (though it doesn't use hardware tokens).
4. Java Applet - This might ultimately be the only way to do it. I've found a couple examples/guides, but I'm not familiar with Java. Java Applet for Signing with a Smart Card. In this case, it's just a simple applet that can communicate with the token, and post the results to the site.
Are there other options available? I believe option (1), Mozilla Javascript Crypto is the best approach, but the documentation is beyond sparse. Thanks for any guidance.
I have virtually examined all options. The last option (Java Applet) is the most appropriate for your case and easiest to implement. The downside is that JRE (Java Runtime Environment) should already be installed at client side and plays nice with the browser. User also has to grant permission to the applet to connect to his smart card at first run.
BTW if you want to use PKCS#7, you can use Bouncy Castle. It has no standard API in JDK.
PS: Don't use JavaScript for cryptography. Javascript Cryptography Considered Harmful.
Maybe you could consider just having the clients download a native application and install it (once). You can have them use that app to do the authentication and negotiate a session key with your server - the app could then launch a browser with the session key in the launch url. "Native" apps could probably be not that native - use java or .net (if you're windows only) or python etc.
I am developing a flex 4.5 web based application and I need to make sure if the client chooses a certain level of security, each user can log only from an authorized computer.
So the question is how can I get some unique computer information? Anything like HDD serial number, CPU specifications, motherboard information, even the user that is logged into the Operating System can do.
So far the information on the web isn't giving me much hope that this can be achieved, but I had to ask.
Thanks in advance.
I suppose the only option available for web application is to create unique id from fields of flash.system.Capabilities class.
Other strategy which can be used is to generate unique UID in process of computer's authorization and then store it in local storage using SharedObject. Then web app tries to read authorization data from SharedObject on web app start. If there is no such data computer isn't authorized.
Richard is right. For security, unique identifying information is not available for applications running through Flash Player. You could write an Active X control (for IE) or a plugin (for Mozilla based browsers) to obtain additional information for your app if users (and their IT administrators) allow it. Information available will vary depending on the browser and operating system the user is running.
Adobe Air, on the other hand, allows access to additional network information including MAC address in the NetworkInfo class. Maybe it's worth considering an installed client app for users who require the additional security. Take a look at: http://www.adobe.com/devnet/air/flex/articles/retrieving_network_interfaces.html
This is not easy using a browser based Flex application, but there are some workarounds.
The browser based Flash Player can communicate with an AIR app on the desktop using localconnection. So, you could create an AIR app that utilizes NativeProcess to retrieve your machine specific information.
You could also use NativeProcess from a AIR app without using the browser at all.
A third option would be to install an application server on the client machine and have the browser based app communicate with the server to retrieve the client information.
I consider most of these options too difficult to be practical, but it depends on how important this feature is to you.
The Flash Player security sandbox will not let you read anything unique about the system on which the SWF is running, so I'm afraid this is not possible. The closest you will get is likely Capabilities.serverString along with maybe IP address, but the serverString property just lists all the capabilities of the client, which is obviously not a unique thing, and also might change from time to time for the same computer.
Warning: my knowledge of server-side scripting is limited to say the least.
This isn't a technical solution, but rather a different approach to your problem.
An alternative solution to would be to inspect the raw packet at the server in order to obtain data such as the IP and MAC address. Based on this the server can then deny or allow the login attempt.
I am used to working on embedded web servers running on micro controllers where C-based black magic is rather common, so I am not sure if this is possible or practical in a more traditional environment.