I know there are many security frameworks and "building" a security framework is a bad idea.
In the recent project I have worked on, I used spring security to secure the web application. In the process, I over rided/tweaked some spring security classes to fit my requirement.
My management now wants me to "takeout" the things I did and distribute it as a re usable code in an internal portal. Now, Is this is a fair thing to ask?
It's not smart. Unfortunately, I don't know enough about what you tweaked or the depth or your management's experience and understanding. My guess is that your management is thinking:
'Wow our engineer made a major security improvement in an established framework, that has got to be worth a lot.'
and 'It's already written, just a little repackaging and sales will be rolling in.'
I tried to explain them it's just some classes build on spring security and nothing special. But they are insisting on "creating" this framework. Is this a fair requirement?
It doesn't seem sound. There seems to be a distinct discrepancy between your view of what you have done and your management's view of it. Your management likely have a better understand of business and product creation, and you likely have a better understanding of technical matters. It may be that your work has incredible product value that your management sees and you don't. However I am more inclined to believe that your work is good but not significantly valuable as a product and your management are mistaken in their enthusiasm.
Let me put it this way. How difficult would it be for a competitor to have a developer of your skill, and for that developer to do work equivalent to what you have done. If the answer is very difficult then as long as there are companies who what what you did you have a product. If the answer is not difficult, then turning your work into a product is more about volume of sales and operational overhead than about technical merit.
Any ideas on how to start?
If you do go forward then spend a sufficient amount of time on requirements and design. Understand what management expects this product to be, and derive design goals from those expectations. Plan for test, release, maintenance, updates, and end of life. Communicate continuously with your management. If you have issues then let management know, sometimes they can help or redirect your efforts.
If I am building this, what are the functions I need to provide?
That will depend on your design goals, which should in turn depend on managements requirements or concept for the product.