• Add a Comment
  • Edit
  • More Actions v
  • Quarantine this Entry

Comments (9)

1 Murali Krishna Thota Sri Jaganatha commented Permalink

Can we use Tivoli Access Manager Authorization Module for authorization when configuring a SAML federation (Browser POST profile)?

2 Shane Weeden commented Permalink

Murali - you certainly could, but what do you want to "authorize" in the case of a SAML Browser-POST operation?

3 Eric Wood commented Permalink

Hi Shane,

 
I like where this is heading but I'm wondering if there's a way to simplify the configuration if everything is deployed on the same STS.
 
What I'd like to do is set up a module that pulls attributes into the STSUU from a database, then applies the XSL transform. It looks like this could be accomplished by using a Delegator module of {database map, default-map} but it doesn't seem to offer me the ability to upload the XSL file anywhere.
 
Thoughts?

4 SHANE WEEDEN commented Permalink

Couple of comments Eric.

 
First, we are likely to phase out XSL for mapping altogether in favour of javascript, so I wouldn't continue to invest heavily in XSL for identity mapping. The main reason for this is precisely what you have suggested - calling external code (Java) is easier and more logical from javascript and less prone to issues with changing XSL runtimes (we've seen issues with this).
 
That leaves you with a couple of choices. You can code you database interaction as a separate TFIM (osgi) plugin and call that from a single javascript mapping rule which is configured in a federation, or (and I prefer this second option), just code what you would have done in an XSL/Javascript mapping module directly into the same pure-java mapping module where you've got your database interaction. You can use GUIXML / config to selectively handle any optional mapping on a per-partner basis.

5 Eric Wood commented Permalink

Thanks, Shane.

 
I like the second option as well, and I think that's what we'll do.
 
I was unaware that you can call java from the javascript module in TFIM. Is there an example of how javascript could call out to an STS module? Just to have another trick up my sleeve is useful.

6 SHANE WEEDEN commented Permalink

To call java from a javascript mapping rule you write your java code in a TFIM (osgi) plugin jar. This is the same technique as writing an STS module, however you just aren't implementing an extension point. Update the MANIFEST.MF to export the packages you want to be able to access from javascript. For example:

 
....
Export-Package: com.ibm.demo
....
 
The plug-in jar file is deployed in the normal manner by copying to <fim install="install" root="root">/plugins and using the admin console to deploy plugins.
 
 
Then in your javascript mapping rule, you import the package at the top of the javascript, and can then access it. For example:
 
 
importPackage(Packages.com.ibm.demo);
 
var myObj = new MyDemoClass();
myObj.myMethod();</fim>

7 Peter Lindqvist commented Permalink

Hi Shane,

 
I saw your post about calling java from a javascript mapping rule but is does not seem to work for me. I just seem to keep getting a ReferenceError saying the class is not defined. This is still supposed to work on TFIM 6.2.2.9, right ?
 
I wrote an STS plugin that exports a package:
Export-Package: x.y.z.auditlog
 
And then in the JS mapping rule I import the package and use a class from it:
 
--clip--
importPackage(Packages.x.y.z.auditlog);
 
var logger = new FIMLogger();
logger.log("Mylog");
--clip--
 
The specific error message I get is:
FBTCON366E
A JavaScript syntax error was encountered when processing the specified mapping rule. The specific error in the log file is [[ReferenceError: "FIMLogger" is not defined
 
Any thoughts?

8 Shane Weeden commented Permalink

When loading a javascript mapping rule into the console, the console will actually try to run it. That's probably what is happening if the error is when trying to load the javascript.

 
There is a trick you can us in your javascript mapping rules to prevent the console from doing this.
 
Take a look at fim_install_root/examples/js_mappings/otp_verify.js, and in particular the logic around this piece of code:
 
if (isInOTPChain) {
... rest of mapping rule ...
}
 
You can do something similar - look to see if there is an STSUU with a non-empty principal name. If so, execute the rule, otherwise skip it (means the console is running the rule).
 
If the problem is during runtime, don't use FIMLogger, instead just use System.out.println when debugging and look in the SystemOut.log of the WAS profile.
 
Finally if you're writing an STS module with your java classes in it, you should write a Java mapping module. This is by far the cleanest approach.

9 Peter Lindqvist commented Permalink

Thanks for the prompt reply!

 
I tried circumventing the verification during uploading the mapping rule but it did not help. My exported package was not available from the javascript.
 
However, we decided on implementing the logic in an Mapping module in pure Java instead, as per your suggestion. It seems to work well.

Add a Comment Add a Comment