i've tried to create a custom component for filenet p8 v3.5. however, as i add it in the component manager, it requires me to create a authentication module??? what is that and how will i create it???

Instead of creating your own Authentication module, you can use out-of-box authentication module which is advisable and saves effort

Hey Robert - I posted that exact same question awhile back, and no one responded. I too would like to know what it is that PE is expected to authenticate into.

The only thing I can think of is that FileNet requires all custom components to implement security on the component itself. If that's the case, then take p8's advice and clone the Authentication Module sample that FileNet provides. Make up a userid/password combination, hardcode it in your module, then specify them in the Component Manager.

That's just my theory. I'm not a J2EE expert, and the people who are J2EE experts aren't coming to the rescue here.

No need to clone the component. Use it as a out-of box feature.

The reason FIleNet need the Secuirty around the Component is because these components are focused to do operations in CE or PE. To do so they need to have a valid session with either CE or PE.

In order to stay in J2EE and liverage the power of authentication layer, FileNet architects decided to use JAAS as a authentication and authorization layer. thanks to the architects. There design has helped FileNet to come with a Extensible authentication module.
It is not a good idea to hard core the username and password inside the component. Use the username and password configured on the JAAS for each specific compoent queue created.

Hope this wil help you. unless let me know we can have a walk through on how it should be implemented. I have implemented the same model at 3 different locations

>>The reason FIleNet need the Secuirty around the Component is because these components are focused to do operations in CE or PE.<<

I think that would be surprising news to a lot of people. That was not my supposition at all.

Be that as it may, here's a question - what credentials are we supposed to be specifying when we create the queue? Are we telling the Component Manager, "expect these credentials from this component", or are we telling Component Manager "use these credentials to attach to this component"?

We are telling component manager to use the specific credentials or you can say Login context for that specific queue.

If you look around the working of CE_Operations (default queue) it creates session with content Engine and then perform various operations.

TO logon to the CE it use the Credentials given at the time of configuring the queue.

Same applies to our custom queues. CELogin Context is a out of box login Context created in JAAS. which can be used by custom components as well

We are telling component manager to use the specific credentials or you can say Login context for that specific queue.

If you look around the working of CE_Operations (default queue) it creates session with content Engine and then perform various operations.

TO logon to the CE it use the Credentials given at the time of configuring the queue.

Same applies to our custom queues. CELogin Context is a out of box login Context created in JAAS. which can be used by custom components as well

And what if my component does not need to log on to anything?

Suppose, for the sake of discussion, that my component adds two numbers and returns the result. Setting aside the wisdom of that approach, what would I specify for credentials when configuring the component queue?

YOu still not to provide the authentication module to the component queue. Unless CM (Component Manager) will not be able to start the component queue.

Any access to the process or content engine must be done with some security information. The component runs under that context, and as a helper to your code, the session can be passed to you. This means you don't need to log on to the CE or PE and that your code doesn't need to worry about security.

If your component needs to do calls to the PE or CE then the component should retrieve the relevant session using the standard documented code segement and use the session to do whatever the component does with it (eg creating work items, updating a document, creating objects in CE).

If your code needs to do something broader and needs to have some security context that isn't the CE or PE context defined for the component, then you can create your own provider code and do what you need.

Sorry, I'm still confused.

I'm trying to draw parallels to the old Visual WorkFlo Perfomer. The components (i.e., COM servers) that act as "passive work performers" have no FileNet content to them - they receive parameters from a client (i.e., VW Performer), and return data to the client. The Performer handles the connectivity to the Workflow engine. By analogy, in P8 my Java component is the COM server, and the Component Manager is the VW Performer.

How does the Component Manager differ from that scenario? If the answer is that these JAAS Credentials are what CM uses to authenticate to PE, I'm okay with that (although JAAS sounds like overkill).

If the answer is that CM is getting involved in helping my component authenticate to systems my component may be using - well, that in my opinion is a design mistake. It's overreaching.

The component manager runs much like the old performer except it doesn't support COM and does support lots of other stuff. It also is event driven rather than the old round robin that performer did, and it's server based rather than on the client.

Internally to your operations its the same behaviour. Each operation should be passed parameters to do the job its written for and pass back the result. The component manager locks the work item, gives you the data and then accepts your data back and dispatches the workitem.

The performer had a huge problem in that your operations had no way of getting access to the session information ithe performer had created, so if you had to do something process or content related in your operation you had to work out how get credentials, logon, handle state etc. The performer only really did process stuff anyway, but components in P8 have to do content, process and a range of other things on behalf of the system. The component manager just gives you the opportunity to retrieve the session info it has already established for the PE and the CE. If you want to extend that and get credentials for other systems in the same way, you can do that through custom authentication code. It provides a consistent way of handling authentication that is already there for the CE and PE, and can be extended if you need to.

Either you don't have to use the session (no PE or CE calls in your methd), or you use the session that is established by the CE and PE (you make PE or CE calls in your method). If you have other applications systems that have security access needs then write your own authentication modue for that application system. For CE and PE its already there.

David, you use terms like "can" and "if", which implies choice. However, CM is *insisting* on credentials. I would simply like to know what those mandatory credentials are for. Does CM need them to log on to the Process Engine?

What I'm inferring from what everyone is telling me is that CM gets involved in the tasks my component is performing, at least from a security standpoint. That's unbelievable to me, which is why I'm having such a hard time understanding.

There are two login defintoins that are relevant. One for the component manager so that it can retrieve, lock and dispatch work and one for each individual component queue.

The first one allows the component manager to logon and retrieve work, get data and dispatch work items, which is normal work performer like behaviour. The second one exists for each component and this authenticates a provided user context, which can be retrieved by your component if you want or need to use it. It ensures that the components are 'secure enough' within the system, but doesn't force you to do anything with the session if you don't want to. If you do, you can retrieve it and use what has been built for you, rather than trying to resolve users, passwords or other system info.

It is mandatory that each component is authenticated, and the easiest thing is to use the default CELogin context which defines the LoginModule for CE/PE access, if you don't need to do anything outside of CE or PE behaviour. If you need to do more than establish an authenticated session within a CE or PE context, then you have to either get or create some code that authenticates the user/password and establishes whatever is needed in a session that can be retrieved by your code, in a JAAS fashion. It's up to the component code to retrieve whatever the login model creates and use it if you want.

FileNet refers you to the SUN site to read up on JAAS, but if you're just doing CE and PE operations, it's unecessary, and even understanding JAAS isn't needed. If you need to build your own LoginModule then you'll need to understand JAAS and build something that the component manager can call to authenticate the user data you provide, and to do any other session building/passing behaviour that your component might need.

FileNet have already built the JAAS style piece for authenticating the session for the CE and PE, and using this technique you can get access to the session that has been created for your component, for CE and PE api calls. This saves you code, storing user info, removes load as the login is done once etc.

If you had to authenticate against a Line of Business system that had an authenticaiton mechanism you could configure it in the config file, create/or use an existing loginmodule that actually implements the required behaviour, and anyone wanting to use your component could have a standard way of providing credentials to your operations, without you building anything, or storing security data anywhere. Access to web services is configured in this way as another area to compare.

There is not one piece of added code if you were building the add integer operation mentioned earlier. It obviously doesn't need any security context so the code doesn't have to have anything different than it normally would. Two integers in, one out, and some code in the middle to add them together. The definition of the component queue does need a security context regardless, and it is mandatory to configure a user/password and context for the component queue and using the basic provided context and login modules is the simplest approach. Your code does what it needs to do, the component manager uses available user id to authenticate the code is allowed to run within the context of the process engine.