Thursday Jan 17, 2008

InfoCard or JavaCard

Kim had posted a nice article on A simple managed payment card example a while ago. So basicaly what happens with a "issued" infocard is that the infocard only contains a pointer to where the user information is to be obtained from (in this case as per Kim's example the issuer happens to be Bank Of America, and the requestor is Well, Kapil had a nicer post on Smartcards and Federated Identity. Kapil quotes
Smartcards are the actually the real enabler of biggest network of identity federations world has known till date i.e GSM. [...] various standards like SAML, Liberty, InfoCard/WS-Trust, WS-Federation etc for identity federation respect and understand the usefulness of security devices like Smartcards. All these standards propose the solution to same set of problems in _almost_ same way and differ mostly in wire protocols used. SAML and Liberty has a profiles ECP (Enhanced client proxy) and LECP (Liberty enabled client or proxy) respectively which enables a Smartcard based authentication where as InfoCard (a profile of WS-Trust) treats Smartcard as another Security token service which can generate self issued security tokens.
nice... I see the light at the end of the tunnel. infocard treats a smartcard as a personal security token service (PSTS) which can issue security token in form of SAML assertions. and so i thought... or rather... continue to think... Whats the difference between the long existent JavaCard/Liberty vs InfoCard/WS-Federation ? I remember sometime back I had read an article on Microsoft Employees Get Carded" by Karen Epper Hoffman via Kapil's Blog. Well, Scott made us use these along from a long time ago... And Microsoft's views on smartcards are no different. Hubert has put together a nice demo of how a using Liberty’s ID-WSF protocols, we can create a module that greatly helps the user in dealing with his digital identities. Currently laptops, sunray 1g, sunray 170 and desktops ARE available with builtin smartcard readers. and hence my dilema...

Java Generics & Backword InCompatibility

After getting numerous non-threatening "warnings" compiling my code using java build 1.5.0_01-b08, I was still bothered about the "warnings" even though my code compiled just fine and worked like a charm. However I decided to cleanup my code to get it to a point whereby I circumvented the "warnings" themselves, and my quest for it led me to the discussions around java 1.5 generics (an emotional one). Since I was using Hashtable(); HashSet(); Hashmap(); etc, I kept getting this error; and all I wanted to do was NEGATE these warnings.

The discussions around Java Generics seem to have been deleted from the sun forums, I am not sure why,

Marc Logemann has a nice writeup on Erasures and the backward compatibility issue However I fixed my issue using declarations as follows: (after I made a few mistakes following the Niel's posts on the same subject, it was my bad as it was "I" who made some wrong assumptions after reading his post)

Hashtable<Object,Object> env = new Hashtable<Object,Object>(5, 0.75f);
Map<Object,Object> map = new HashMap<Object,Object>();

I am reposting this here so that folks who still have questions on how to fix these warnings, could help themselves by just changing the method by which the declarations are made. You can also follow the links on this post to get deeper insight into why this change was made, and the reasoning behind it.

I really hope that this helps you folks as, I had to do some serious digging/searching before I found the answers for what I was looking for.

Also read Ken Arnold's, Jason Hunter's, John Mitchell's, Weigi Gao's, Antonio Cisternino's, Tim Jansen's, and Bruce Eckel's blog.

For information about generics and the core generification, see JSR 14 and the generics tutorial (PDF).

Java Cards - A MUST HAVE

By this coming Monday all major federal agencies are required to submit detailed implementation plans to the White House Office of Management and Budget that describe how they plan to meet the smart-card requirements outlined in Federal Information Processing Standard (FIPS) 201 (download PDF). The 2004 presidential directive requires all federal government agencies to use smart cards to authenticate employees for access to resources.
The requirements stem from Homeland Security Presidential Directive 12, which calls for electronic identity cards to be issued to all federal employees and contractors as part of a bid to better secure access to government facilities and information systems. The cards must support two-factor authentication via digital certificates, a password or personal identification number, and biometric identifiers. They also are expected to be interoperable across all federal agencies.
SmartCards aka Java Cards are effective... very very effective. The Java Card Development Kit, includes a complete environment in which applets written for the Java Card platform can be developed and tested. It enables developers to create applets that utilize the features of the Java Card API. Now : This technology is not something new. We've been at it for ages... Why do folks shudder with reluctance when they are given new technologies to play with? Well, ask us, and we shall show you how ;-) According to this report, Taiwan had distributed Java Cards to it's population (22 million) way back in 2003. So did Taiwan, India, China and others... (I just cannot find those reports, I shall provide you links to those reports as soon as I find them) This article that dates back to 2000 would show you that we truly are the early adopters of this technology. So why is the federal sector still fumbling with their deadline for deployment soon approaching.
Sometimes It's best to let the experts show you the way. Why not ? Haven't you seen the Sun folks walking around with Java Cards for a while now ?
and hey, The DoD nomenclature for Java Cards is CAC (Common Access Card), and who do you think is behind it ?? Well, truthfully, the peices of plastic are from Schlumberger, the card readers for windows are from ActiveCard and THE REST, By US !!! ;-)
Other Resources
Java Card technology is one of the best secure authentication technologies for trust, privacy and verification of identity on the network, deployed in way over 500 million smart card and mobile phone environments around the world. Sun is building on this success and applying its expertise to the Windows environment though inclusion of Java Card technology support in its Java Desktop System and Java software systems. This model will not only secure access to the device (mobile handset, desktop or infrastructure), but access to network services, and ultimately access to and distribution of content. This guarantees authentication of the device, of the sender, and of content represented, helping reduce victimization through fraudulent Web sites, and e-mail spam and viruses.
Think about it feds.. You got our number.. (and if you didnt know it, it's +1-800-786-0404)

Wednesday Jan 16, 2008

my Java Desktop : Smashingly Impressive !

[My Java Desktop]

Here's a Screenshot of My Java Desktop. It's so neat and spiffy that I am extremely happy that I have it running on my laptop. When I first installed the Java Desktop on my laptop. everybody around me told me that I was making a brave move. "Think about the graphic applications that you use rohan, how could you generate graphics using JDS, whats gonna happen to Adobe Photoshop? what about dual boot system with Windows XP also running on it, so you are not rendered laptop-less"; well; i tell you, warnings flew left right and center. I didnt hesitate a bit before installing JDS on "my" laptop. & hey !! no dual-boot. I went all the way. Kind of like what my swimming instructor did to me when I was little : he told me to go all the way, just like what my "then" fiance (now 'wife") told me when we spoke about going steady: she said "go all the way rohan, I promise you that you will not regret it". I have never gotten to regret anything so far... so I took the plunge. Java Desktop. All the way. And hey !! I use GIMP for graphics, it's way cool, easy and though I would not say that it outbeats Adobe Photoshop, it's good enough., I use Evolution for my corporate email, thunderbird for persomal email, firefox for my internet browser, mozilla for intranet, and Staroffice. Who says that one would have issues with word documents, I can not only read word documents in StarOffice, I can also create them !!, not to forget presentation, spreadsheets, drawings, charts, workflow, diagrams the works !!. am i so happy I took the plunge ! you bet I am. So IF you are thinking about using it, I say GO FOR IT : ALL THE WAY; and in case you need help as you go along there's always jdshelp, and the community Here is another screenshot:

[Sun Java Desktop Screenshots]
BTW : The images here are all made with GIMP. And speaking about my "then" fiance, now "wife", asking me to go all the way, look what I'm got now, "roti:kapda:makaan". (for the non desi's it meant food:clothing:home) Aint that the bare necessities ?.

Tuesday Jan 15, 2008

Java Native Interface (JNI)

was breaking my head over a methodology to come up with a unique identifier for storing entries in a LDAP server. Entries stored in the system could have been sourced from varied applicates and datasources, and the probability of entries having the same unique identifier as another entry sources from another system was very high. Initially thought of using the conventional Social security Number, but then learnt that SSN's were not unique. also toggled thoughts between using sequential numbers, first, middle and last name combinations etc. After all the thought wondered if others never encountered such issues when having to provision systems from varied sources and ensuring that all sources sent a unique identifier when performing the addition to the LDAP server?

So after all the brain racking came up with a probable neat way of ensuring that the numbers were unique using JNI!!. wrote a simple "C" API that concatenated the MAC address of the machine with the EPOC timestamp and the time since last reboot in nanoseconds. This have me a 16 bit number that was unique to the nanosecond. Well, I have a unique identifier now, But how could I use it was my next hurdle.

After a little more pondering (googling and discussing approach methodologies with friends), realized that with JNI available, life of bridging the gap between java and native code was made much simpler.

I used the tutorial written by Beth Sterns to build my JNI Interface. So if any of you out there ponder on how to use and build JNI interfaces, I'd recommend the Beth Sterns Tutorial anyday !!!. It sure did make my life easy, and I bet it would do the same to yours too..

There also is a MAC OS Runtime for thos MAC geeks.

"Note that the ability to load dynamic libraries is subject to approval by the current security manager. When working with native methods, you must load dynamic libraries. Some applets may not be able to use native methods because the browser or viewer they are running in restricts the ability to load dynamic libraries. See Security Restrictions for information about the security restrictions placed on applets. "

Java Desktop

SUN JAVA loading image.. please waitAfter waiting for a long while resisting the usage of the Sun Java Desktop, I finally installed it on my laptop today. The reason being an urge to do so from the higher authority. Well, I now ponder on why it took me so long to have it installed on my laptop. I love the technology, but yet I hesitated. Why, Why, Why ? is what I ask myself. I deploy solutions and recommed the technology and products based on this technology to anybody (person or organization), yet I hesitated to use it myself. Well, I guess it's just the fear of having to deal with files that I receive from customers that may render me helpless in viewing them or using/modifying them on my JDS laptop. I usually receive tons of Microsoft Exchnage meeting requests, visio diagrams, Microsoft project files etc.. and my fear is, that if I need to spend more time trying to simply access those files, which may render my productivity response times a litle bit slower than the usual, the customers and clients that I deal with my may have a laugh about our own methods of client interaction. So, all said and done, after the initial hesitation, finally have JDS on my laptop. NOW: my fears still exists, but let me take each day as it comes, and see what happens next. I'd hate to revert back to the old XP, but anyways... lets see how this all goes. Who knows I may just as well have a dual boot system on my laptop and have both JDS and XP. maybe Sun should sell JDS bundles to all laptop manufacturers to bundle JDS with their products. Maybe then nobody would every worry about incompatible software etc... "A computer on every office desk" might as well be read as "A java Desktop on every computer"

Saturday Nov 04, 2006

Worlds FIRST Java Based infocard RP - LIVE

Chuck Mortimore has just deployed the world first Java Based Infocard Relying Party app. I'm following up soon with a PHP based Relying Party app... (Chuck beat me to it.. even though we've been constantly communicating and collaborating.. Guess Chuck's had the advantage of time... But However, We played tag-team and managed to get it to work !!!) Getting Java to work was easy.. PHP seems to be a bit harder with decoding and parsing encoded XML. I always thought that PHP was easier.. But was proven wrong this time... I'm trying to do exactly the same thing in PHP as the Java code and all I get is garbage. There must be something different in the urldecode / base64_decode functions in PHP and the way in which it handles "special characters". HOWEVER: Chuck's the one who deserves 100% credit for deploying it first. Kim, Please publish your code... not the relying party provider (RP) code, We got that already.. We would like to see the WinFx Identity Invoker Code... (please... please... please... please... please...) For those who appreciate HARD WORK. Take a moment to toast Chuck. Infinite cheers Chuck !!! You ROCK !!! Open Source rocks !!!..... Kim.. break down those walls. Let East Meet West. Let infocard be really "open". Please do not restrict us to work within those "infocard walled gardens"... please let us open up channels to securing the identity space. & ah !! in-ter-oh-por-ate !! PS: When I say "us".. I mean "we the people", @the "open source community".... ;-) Next Stop: How to Federate your "infocard" authentication token.

Friday Nov 03, 2006

Yet Another Infocard Java Based Infocard RP

AH!!! Hellooo world. Java based infocards are taking over... Here's Yet another Java Based Infocard Relying Party Demo. This time It's Ashish Jain's implementation of it. Ashish works for PingIdentity and is also the co-author of J2EE 1.4 Bible & Enterprise SOA (I bet you didnt need that introduction, as you would have known that already.). His demo is available at pingidentity's Jetty Based demo server. His implementaion however does not use bouncycastle or XOM but is again a Java based RP developed from scratch using XMLBeans and XMLSEC. It sure is a chweeth Object Oriented world aint it ?? UPDATE : There's one thing for sure that infocard and WS-\* is helping me with. IE: Making new connections and a LOT of new friends.

OPEN infocard

Chuck Mortimore, has posted the exact steps required to "consume" infocards on his blog (xmldap). I'm not gonna steal the spotlight from him. He deserves more credit for this than anybody else. This is a cross post from Chuck's blog. Chuck writes:
To get started, you need to get your hands on the XML Token. This should be pretty simple, as your web framework will generally hand back parameters already URL decoded. Once you’ve got the token, you’ll need to decrypt the token. The token is transmitted as encrypted XML.
Head On Over to Chuck's Blog to see what the xmlToken would look like
OR look at my previous post on what it looks like. Chuck's Post is "complete". Mine's truncated..
Basically what you have here is an ephemeral symmetric encryption key, which has itself been encrypted with the Public Key of the SSL Cert for the website InfoCard is interacting with. As you can see from the metadata provided in the KeyInfo fragment, the key is encrypted using RSA with OAEP encoding and SHA1, using the certificate identified in the SecurityTokenReference with the provided fingerprint (the fingerprint is a SHA1 hash of the cert bytes) Your first job is to decrypt that encryption key. Step one : remove the Base64 encoding. Step 2 : you need to write a function which takes the private key for the cert referenced by the fingerprint, along with the data as input, and decrypts in this manner RSA-OAEP Once you’ve successfully decrypted the key ( it should be 256 bits), you can use it to decrypt the token. As you can see in the XML, you need to use AES with a ChainedBlockCipher. Decrypt the token (Don’t forget to strip the initialization vectors...thanks Gary).
Head On Over to Chuck's Blog to see what the decrypted token would look like
The next step would be to quickly check the validity period on this Assertion to make sure it’s still fresh. You might also want to check the AssertionID against a table of previously seen assertions to prevent replay...depends on your level of paranoia. On to signature should follow the steps outlined in XML-DSIG, but to paraphrase, check the digest of the canonicalized assetion against the digest in the SignedInfo block, and then validate the signature of the canonicalized SignedInfo using a PublicKey constructed from the provided KeyInfo. Now, what’s bugging me is the use for the Symmetric Proof key provided in the Subject of the Assertion. Super Pat and I discussed this for awhile, and since it’s not used immediately in this protocol exchange, our best guess is that it’s used in subsequent interactions with the service, although I must admit the InfoCard docs are a little fuzzy on this subject. If anyone can fill me in, I’d appreciate it! Finally, if your signature validation worked, extract the claims, enforce any policy you’d like, create a session, set a cookie, etc...
Chuck has also reverse-engineered the infocard token creation and has published a tool that can create a token for you on his demo servers. Now since "infocard walled garden" has been made not so mystical, Here's are my thoughts. The OBJECT tag required to invoke the Identity Selector is a cool tool, But on the RP side, the RP is just a listener that received tokens "pushed" to it. One does not really need the use of a InformationCardSignInHelper (ie: icardie.dll for ie7)to invoke the Identity Selector (WinFX CTP). One can easily write a tool, that creates these tokens using random data and start pushing these tokens to RP's. I see this as an extremely simple way to set up a DoS attack.
  • So are infocards really "secure"?
  • Would they make the common man's life easier?
  • Would they make RP's more vulnerable to DoS attacks?
Like I said earlier, I am having a extremely hard time trying to digest the First Law from the "Laws Of Identity". For some reason I tend to lean strongly towards not being able to digest "user control". Hopefully over time, I shall grow out of it and be able to digest the theory. SO: Higgins folks have a base to work off of for their open source version of "infocard-whatever" (not that they needed it). And I'd like to see if folks credit Chuck for HIS hard work.

for everything on Identity, JCAPS, SOA, WebServices, Security, Single Signon, Federation, Provisioning, Virtualization, Optimization, Debugging, Workflows, Compliance, MySQL and more... WAY MORE....

[this is a group blog]


« June 2016