Good Afternoon. If someone(s) could provide a little assistance, I would appreciate it.
We have installed and implemented WebFocus 7.6.2 at the client site and have developed a series of reports and released them to the users complete with web login screens and passwords. Life is generally good...or was until it was pointed out that, as we are handling federal data, the fed requires certain security measures to be in place. Does WebFocus provide mechanisms to regulate or permit the following:

1) setting a minimum length for passwords
2) setting an expiration schedule for passwords
3) limiting password availability ie - can't be any of the last six used
4) prompts to change passwords
5) account lockout after 3 unsuccessful attempts

If not, is anyone aware of any workarounds?

This of course is an abbreviated list but catches the high points.

Thanks in advance,

Rich

Rich,

Please provide the list of products, releases, platforms, etc. in your profile signature so that we can better help you.

Are these reports MRE or self-service?

If MRE, you might want to look at an external security package like LDAP to secure MRE.

If self service, the operating system and site usually provide all of the restrictions you are talking about.

We are AIX self service and most of the list that you have specified are provided by AIX.

Rich,

Is using an external AUTHENTICATION method a possibility?

For example, authenticating against Windows Active Directory (A/D) (or LDAP) allows you to require your MR users to authenticate with their "Windows" or system credentials. Because this mechanism uses your corporate authentication mechanism, whatever rules you have for A/D or LDAP would apply for MR users by WebFOCUS as well.

A basic "A/D Authentication;Internal (or External) Authorization" is pretty easy to impliment). It's discussed in Chapter 7 of the "WebFOCUS Security and Administration" manual.

What's nice about doing "just the authentication" is that, if you lock out a user from Windows (e.g. when someone leaves the organization), their also locked out of WebFOCUS, regardless of where you store the AUTHORIZATION schema.

Another option would be Integrated Windows Authentication (IWA) - Single Sign-On. This option requires an authenticating Web Server (e.g. Microsoft IIS). The user is authenicated to Active Directory via the Web Server; then that ID is passed through to MR; which is configured to trust the ID that IIS passed to it. This is also covered in the "WebFOCUS Security and Administration" manual.

I hope this helps.

Rich,

What security is being used by WebFOCUS?

I'm pretty sure you want to look into External Authentication and maybe even External Authorization.

For example, you can use Active Directory for Authentication. There you can have rules to lockout userid after 3 unsucessful attempts, minimum password length, etc.


Thanks,
Sayed

Sorry about that Jenny. Had the data in my profile but not signature. Should be updated now. Thanks for the heads up.
Not sure how MRE vs self serve is defined as I am relatively new to the whole WebFocus terminology thing, but we have about 20 propmted reports made available to users via the web, developers creating reports to migrate to Managed Reporting Production and a handful of users who can create ad-hoc reports.

As apparently WebFocus itself only offers basic security, we are considering Microsoft Active Directory in order to be covered under the existing network setup. Am trying to figure that out now.

Thanks for your help.

RJ

Thanks Jim. I appreciate the options. Will look at CH7 online here and see what I can't figure out. Not really familiar with network security issues and was hoping the WebFocus tool would give me an easy interface for modifying password properties there, but that doesn't look like a possibility. I'll see if I cant figure out Active Directory.

Thanks,

RJ

Sayed -
Thanks for the info. Looks like Active Directory is going to be the way to go. Right now, security involves webfocus ids and pwds for our users, but I can't get the control of the system that is reuired through webfocus alone. I'll look at the dox and see what I can figure out.

I appreciate the help.

RJ

If your application(s) are Managed Reporting, there are many out-of-the-box options for integrating with a customer's existing security model, including LDAP, Active Directory, ClearTrust Kerberos and SiteMinder to name a few. These are easily configured using the Managed Reporting Realm Driver accessible from the WebFOCUS Administration Console. You can also split the security inplementation between authentication and role-based authorization.

If you are in a self-service implementation, you are on your own to develop hooks into the existing security. Self-service is as it implies. The customer is responsible for all aspects of application management, including security, portal, etc.

For utilizing the Managed Reporting realm driver, you can find out more about your security options by downloading the WebFOCUS Security Administration Manual. The information that you will need to concentrate on is contained in Chapters 7 and 8

Rich,

We also have similar requirements to yours popping up here. However we were hoping to be able to seamlessly handle user acounts for both our self-service apps and our MRE apps, but it doesn't sound like this is possible based on the feedback so far.

Ginny,

Could you kindly elaborate on how you integrate your apps' user signons with your AIX Unix accounts. We currently store our user account data in an Oracle table, and don't create Unix accounts for our users. So I'm curious how you manage that.

Thanks!
Sean

Hi, Sean.

I'd be happy to elaborate. We are almost 100% self-service here and most data access is done against adapter connection strings with default ids stored in edasprof. All of our developers have AIX ids, of course.

There were two situations, mainframe DB2 and secure Teradata, where we didn't want to put default read connections in edasprof. For mainframe DB2, we don't have any connection string at all. For Teradata (which is a warehouse) we have a read id connection but by the end of the year it will only have access to public views.

The other problem was how to get users who weren't developers access to data on reports to which they were authorized without having to get them unix ids.

We contracted with IBI Consulting to write an LDAP exit for us. A WF client profile for a special client node we call WFEXTSEC runs the exit which validates the user's credentials against LDAP, puts the user's credentials in new variables called &LDAP_user and &LDAP_pass and replaces the IBIC variables with an application id with a non-expiring password to do the unix authentication. The variables are saved for the session in case there is a drilldown.

In the report, the developers code a -INCLUDE connect program which is encrypted. In these connect programs, the connection to the data source is made using the LDAP variables I mentioned previously.

When the developers create their applications, there must be a logon page (we use the standard one provided by IBI which we've dolled up) which references the WFEXTSEC node and this page either calls a lauch page if there are parms (and this page must also reference IBIC_server=WFEXTSEC) or the program itself.

So non-secure apps can use EDASERVE and the secure ones can use WFEXTSEC. This methodology works well to secure apps that don't access secure data necessarily. The developer can test &LDAP_user against a list of registered users for their application.

This is a lot of information. Let me know what you don't understand or if you have more questions.

Smiths,

One way you can accomplish this is to secure your WebFOCUS reporting server via the DBMS option and then secure your WebFOCUS client to the WFRS.

Chuck,

That works great (as we also have a password passthru Teradata reporting server) if you only have one adapter to secure. We have at least 3 and you can only secure one adapter per password passthru server.

Ginny,

Thanks very much for taking the time to share that with me!

Yes, it is a lot of info for sure, and only being at the beginning stage of learning this, I might have more questions further down the road (thanks for offering!).

I'm reading up a bit, and we also had our IBI rep looking into it, so my understanding of all this will advance. It's great to see how other folks are handling their security requirements.

Chuck, thanks for your input also!

Sean