Friday Mar 09, 2007

Welcome, Mrudul!

A big shout down the corridor to Mrudul Uchil, lead engineer on Web services security and Java EE SDK/NetBeans Enterprise Pack integration in the Access Manager team. Mrudul just started blogging - anyone working with the new Web services security features in Access Manager 7.1 or looking forward to this technology appearing in OpenSSO needs to subscribe to Mrudul's blog.

Thursday Mar 01, 2007

Sun Java System Access Manager 7.1 is here!

You might have seen the news today that Sun just released Java Enterprise System 5. While it's not called out in the press release, Sun Java System Access Manager 7.1 is part of Java ES 5. Although it's been widely previewed in beta in the Netbeans Enterprise Pack and Java EE SDK, it's still worth calling out the new features:

So, go to the download page, grab Access Manager 7.1 and give it a whirl. It's in all of the system/suite downloads except the availability suite.

Thursday Feb 22, 2007

Turkcell Deploying Mobile Strong Authentication

From Orhan Alkan comes this report of Turkcell deploying mobile strong authentication with Sun Java System Access Manager. Orhan and his colleagues in the Sun Turkey Professional Services team developed a custom authentication module to handle the signature validation in Access Manager.

Orhan was kind enough to give me some more detail by email: the subscriber's private key is in the SIM, so it is portable across phones. Authenticated subscribers can access all of Turkcell's web-based customer applications including billing, enabling services such as international calls and roaming and changing rate plans, and even access their accounts at banks such as Garanti, Akbank and Isbankasi.

Recalling an earlier entry on Turkcell's ID-WSF pilot - they certainly seem to be in the vanguard of mobile operators when it comes to identity.

Thursday Dec 21, 2006

Access Manager training class in Amersfoort, Netherlands

A while ago I blogged about the Access Manager 'Configuration and Customization' training course in Burlington, MA, presented by Allan Foster. Well, I've just heard that Allan is presenting it again in Amersfoort in the Netherlands, on January 22nd. If you're in Western Europe and you want a great grounding in AM, you might just want to go...

Monday Dec 04, 2006

Sun and Microsoft Interoperate for Web Authentication, Part 1

In between all the talk of federation, PHP and web services, we sometimes lose sight of the fact that bread-and-butter single sign-on and access control still has huge value in improving both security and the user experience. Over at the Sun Developer Network, Marina Sum and I just published an article - Sun and Microsoft Interoperate for Web Authentication, Part 1 - focusing on how Sun Java System Access Manager and its policy agents integrate with Microsoft IIS to provide both single sign-on and access control - right down to Windows ACLs on files on disk.

As the article mentions, some functionality (specifically, the basic authentication plugin - from the 'Configuration of the Policy Agent for HTTP Basic Authentication' heading to the end - sorry, there is no handy name anchor in there to link to) will be released in AM Policy Agent for IIS 2.2-Hotpatch6 sometime in the next few weeks. I'll post here as soon as this is available; at that point you will be able to work through the entire article. In the meantime, much of it works with the current policy agent, so you can get started straight away.

Monday Nov 13, 2006

Access Manager training class in Burlington, MA

There are a small number of places available on the Sun Java System Access Manager: Configuration and Customization (AM-3480) at Sun's training center in Burlington, MA the week of Dec 4. This presentation of the course is taught by the most excellent Allan Foster; Allan taught the recent Federation Manager Boot Camp course on which Hubert heaped lavish praise, so you know you're in good hands.

If you're in the North-East and you feel your AM knowledge is lacking, then take a look and consider signing up - your department may well have some training budget that needs to be used or lost before the end of the year...

Wednesday Sep 20, 2006

New Access Manager articles on BigAdmin

Normal blogging service was disrupted somewhat by last week's DIDW and IOS. Among many snippets in my 'to blog' pile, here are links to a couple of recent 'hands-on' articles from Sun's BigAdmin site:

If this sort of stuff lights your fire, then you probably want to subscribe to the monthly BigAdmin newsletter.

Wednesday Sep 06, 2006

Sun Developer Network Channel - Identity Management Month

Sun Developer Network's SDN Channel this month focuses on Identity Management. There's a cool video featuring my esteemed colleague - Identity Guru Aravindan Ranganathan. Aravindan looks at some of the latest web services security features in Sun Java System Access Manager 7.1, bringing a new twist to that old staple web service sample - the stock ticker - by allowing only authenticated users to obtain real-time quotes. If you want to try this at home, the beta of Access Manager 7.1 is available now in the Java EE SDK download.

There's a whole load more useful information (and a link to a short article I wrote on open source identity at Sun) in the SDN Show Notes.

Thursday Jun 29, 2006

Fresh out of college? Coding hero? Looking for a challenge?

Access Manager is hiring!

Are you a recent graduate? Know some Java? Interested in working in identity management - one of the most dynamic sectors of the software industry? Ready to show your coding skills to the world in an open source project?

Sun's Identity Management engineering group has a vacancy for an entry-level coder. Click here, and tell 'em Pat sent you.

We're looking for more experienced code wranglers, too!

Wednesday May 24, 2006

Quick Guide to Access Manager 7.0 Site Configuation

This came across the internal Access Manager mailing list today. It's too good not to post. Many thanks to David, Beomsuk and Subash for compiling this.

Overview

Site configuration in AM 7.0 provides a facility that lets Access Manager clients communicate with load-balanced Access Manager instances. While this was possible in Access Manager 6.x, site configuration provides several advantages:

  • Access Manager instance URLs are not held in state by Access Manager clients
  • Configuration is far easier and less error-prone than with Access Manager 6.x
  • Site configuration supports deployments with multiple load balancers, and with firewalls around each site, with no changes required to firewall configuration

Access Manager 6.x Naming Table on Client Side

All Access Manager clients use a naming URL stored in the client configuration (usually AMAgent.properties) to retrieve a client-side naming table, which is held in state on the client. For 6.x clients, the client-side naming table holds the URLs of needed Access Manager services for each Access Manager instance. The URLs refer to the Access Manager instances. Thus, information about servers that are likely secured behind firewalls are held in client state, which is a potential security problem.

Client to Access Manager Instance Access in AM 6.x

When a 6.x Access Manager client accesses an Access Manager instance on behalf of a user attempting to access a web app, it accesses the instance directly (assuming the user has a valid SSO token). Depending on the Access Manager service required, the client dynamically build the URL for the service based on the instance ID stored in the session token and the URLs in the naming service table. A load balancer fronting the Access Manager instances is ignored in this scenario.

This works fine as long as there is not a firewall in between the client and Access Manager instances. In this case, the client is not able to get through the firewall to the required URL on the Access Manager.

So in the scenario in which multiple Access Manager instances are fronted by a load balancer, with a firewall somewhere in the mix, it is necessary for the Access Manager client to go to the load balancer instead of directly to the Access Manager instance.

You can force an Access Manager client to do this either by setting up the /etc/hosts file so that all the FQDNs of the Access Manager instances point to the IP address of the load balancer, or by setting the com.iplanet.am. naming.ignoreNamingService property to true.

Therefore, each client has to have this property set, and whether the property should be set or not is dependent on the location of firewalls and load balancers in the topology.

Access Manager 7.0 Naming Table on Client Side with Sites Defined on Access Manager

For 7.0 clients, if a site is defined in the platform service, the client-side naming table holds the URLs of needed Access Manager services for each Access Manager site. The URLs refer to the Access Manager sites - load balancers - and not instances. Thus, information about servers that are likely secured behind firewalls are not held in client state, eliminating the potential security problem from 6.x.

Client to Access Manager Instance Access in AM 7.0 with Sites Defined on Access Manager

When a 7.0 Access Manager client accesses an Access Manager instance on behalf of a user attempting to access a web app, it accesses the Access Manager site (assuming the user has a valid SSO token). Depending on the Access Manager service required, the client dynamically builds the URL for the service based on the site ID stored in the session token and the URLs in the naming service table. Therefore, all requests go through a load balancer.

If there is not a firewall in between the client and Access Manager instances, it is not a problem, because the client should be able to get to the load balancer.

There is no need for any special configuration on the client to make this all work. As long as the nameing URL points to the load balancer, all is well.

Multiple Site Support in 7.0

Consider the case where you have multiple sites. Suppose you have:

  • A Web Server in San Francisco with a protected URL
  • A Web Server in Tampa with a protected URL
  • An Access Manager site with a load balancer and multiple firewalled AM instances in San Francisco
  • An Access Manager site with a load balancer and multiple firewalled AM instances in Tampa

You want an end user who has authenticated with the San Francisco site to be able to access the protected URL in the Tampa without re-authenticating.

In 7.0, with sites configured in the Platform Service, an Access Manager instance in San Francisco is able to perform session validation on an Access Manager instance in Tampa by referencing the Tampa load balancer.

In 6.3, although enabling the com.iplanet.am. naming.ignoreNamingService property might let the San Francisco \*agent\* get to the Tampa load balancer, there is no way for an Access Manager instance in San Francisco to get to the Tampa load balancer for session validation. An Access Manager instance in San Francisco can only reference the Access Manager instances in Tampa defined in the platform service. So, if these instances are firewalled, the SFO AM instance cannot reach the Tampa instance.

Making a multiple site deployment work in 6.3 requires firewall configuration in ways that are likely to be unacceptable to users.

If No Sites Are Defined in 7.0

Access Manager should work identically to how it worked in 6.x. You can define configurations with multiple instances in the platform service, configure the fqdnMap, and add realm DNS aliases as needed. But if there is a firewall behind the load balancer, the deployment will fail.

Server-Side Configuration in Access Manager 7.0

To configure Access Manager 7.0 to support sites, you need only do the following:

  • Define the site and instance lists in the platform service
  • Add realm DNS aliases as required in the realm properties for the top-level realm

Server-Side Configuration in Access Manager 6.x

To configure Access Manager 6.x to support multiple instances, do the following:

  • Define instances in the Platform Service
  • Define the fqdnMap property in the AMConfig.properties file
  • Add realm DNS aliases as required in the realm properties for the top-level realm
  • Configure clients as necessary, depending on firewall locations

Summary

The 7.0 site configuration capability provides enhancements to Access Manager security and ease of configuration.

Tuesday May 23, 2006

Access Manager 7.1 Beta in Java EE Tools/NetBeans 5.5 Enterprise Pack

If you've been following Eric Leach's blog, you'll know that, just before JavaOne, we released a beta version of Sun Java System Access Manager 7.1 via a couple of bundles:

The former download is 132 MB, the latter 89 MB. The main difference between them seems to be that the Java EE 5 Tools Bundle includes NetBeans; NB EP 5.5 assumes you already have it.

Access Manager's role in this bundle is to secure web services. If you're thinking "Uh oh - this is that Liberty stuff they keep pushing at me; I've barely got my head around basic SAML assertions, let alone ID-WSF.", well - relax. We did show Access Manager working with Java Studio Enterprise and JSR 196 (Java Authentication Service Provider Interface for Containers) to secure web services via Liberty ID-WSF at last year's JavaOne (there's also a technical article on the topic); since then we have implemented WS-I BSP to secure 'plain vanilla' web services.

Here are my notes from installing the Java EE 5 Tools Bundle Beta and working through the Securing Web Services tutorial. I'm running Ubuntu 6.06 'Dapper Drake' Beta. Not an officially supported platform, but I like to surf the bleeding edge

  • Let's get started. I downloaded the Java EE 5 Tools Bundle Beta, chmod +x netbeans-5_5-ide-entpack-sdk-jbi-am-linux.sh; ./netbeans-5_5-ide-entpack-sdk-jbi-am-linux.sh and I'm into the installer. I need to tell the installer where I've put Java - it doesn't seem to know. Fair enough - this is not a standard system - I have at least three versions of Java floating around.
  • The installer prompts me for ports, passwords and trundles away for a while. On completion it reports that there were some warnings. I check /tmp/netbeans-5_5-installation-20060523143837.41310.log and it looks like the installer was not able to get to Access Manager (AM) at http://myhostname:8080/amserver/configurator.jsp. Ah - that's probably because it likes your system to have a fully qualified domain name (FQDN), e.g. myhostname.mydomain.com and I don't have a domain set. This is documented in the release notes - it doesn't seem to be a big deal, and I can get to that URL in Firefox, so we'll just carry on.
  • OK - surf to http://myhostname:8080/amserver/configurator.jsp and I get a nice configuration page:

    Those are the 5 parameters you need to set to configure AM. I left everything as default and (as expected from the release notes) got a server error. Putting a dummy domain on the end of the hostname did the trick and I'm at an Access Manager login screen.

    Cool! The simplest ever AM install/config
  • Login with the default amadmin/admin123 (we'll have to change that - I hate default passwords. We should add 'amadmin password' to the 5 configuration parameters) and I'm in the now familiar AM 7.x admin UI:
  • Ok - install and config done. On to the Securing Web Services tutorial. The tutorial notes are a little sketchy - I'll fill in the gaps here as I go along.
  • Grab the stockapp.zip sample source and put it somewhere sensible, as suggested in the tutorial. I get two directories, stockclient and stockservice. Cool.
  • Tutorial step 2 is missing an initial steplet - you need to go to the App Server admin console at http://myhostname:4848/ and login as admin with whatever AS password you selected at install. Hmm - I don't see a 'Runtime' tab, but I can see a running App Server (in fact, I already checked that it was running by browsing http://myhostname:8080/ and, of course, I wouldn't have been able to configure AM if it wasn't running. So, according to step 2c, I can safely skip forward to step 5 in the tutorial. Except that it seems like the next thing I have to do is in step 3.
  • Tutorial step 3 - yes - done this already.
  • Step 4 - ah - you will definitely want to do this - set AM to full message debug logging. On my system, the config file was at /home/pat/SUNWappserver/addons/amserver/AMConfig.properties. Beware - there is another AMConfig.properties file for the AM server - on my machine it's at /home/pat/AMConfig.properties. If you set message debug logging at the AM server but not in the AS addons, you won't get any of the diagnostic output described below. I know - I did exactly this first time round and spent several hours trying to figure out what was wrong. Change com.iplanet.services.debug.level to message and restart the App Server. Just go to wherever_you_installed_it/SUNWappserver/bin and do ./asadmin stop-domain; ./asadmin start-domain.
  • Step 5 - Run NetBeans and disable proxies as directed in the tutorial, since we'll be interacting with local services.
  • OK - now for some secure web service action... Start NetBeans and... Oh. NetBeans just shows me a blank window. That's not good. Google Google Google... Ah. I have XGL and Compiz eye candy installed. This forum post gives the answer - run the Xnest nested X server, the icewm window manager and then run NetBeans in the nested X session. Fair enough. Ubuntu recommends Xephyr rather than Xnest, so I grab that, icewm and.. great - we have NetBeans! [UPDATE: See this comment for a handy little script I wrote to run NetBeans in a nested X session.] Back to the tutorial...
  • Open the two projects. Cool - Web Service Provider (WSP) Security Configuration property page. Enable security, select SAML-HolderOfKey, sign reponses. Don't forget to change the password if you overrode the default AS 'adminadmin' password. Ooh - we'll have to fix that password entry field. This is beta, don't forget.
  • We can go look in the keystore, just to check that we are supplying the right password here, and that the s1as cert is there:
    pat@patlinux:~/SUNWappserver/domains/domain1/config$ keytool -list 
    -keystore ./keystore.jks -storepass password
    
    Keystore type: jks
    Keystore provider: SUN
    
    Your keystore contains 1 entry
    
    s1as, May 23, 2006, keyEntry,
    
  • Now to the client... Web Service Client (WSC) Security Configuration, enable security, SAML-HolderOfKey, verify response. Check that password again. And we're ready to run. Build and deploy stockservice as described in the tutorial. Build and run stockclient and we have a JSP ready for input. I had to copy the URL into the browser in my main X session, since Firefox wasn't happy running a second instance in the nested X session. I also had to change 'localhost' in the URL to my real hostname.
  • Now I just press enter to get a quote for SUNW and... I get a page of canned price data. It works!!! On my machine, ClientModule and ServerModule are in /tmp/amserver/, I can see real, honest to goodness WS-I BSP SOAP messages with SAML assertions in the headers. I've indented for clarity and elided most of the base 64 encoded signature and key info.
  • Here's the raw SOAP message as it leaves the client code (don't forget, the whole point of this is to abstract the security stuff out of the client/server code):
  • <env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/" xmlns:enc="http://schemas.xmlsoap.org/soap/encoding/" xmlns:ns0="http://sun.com/stockquote.xsd" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
      <env:Body>
        <ns0:QuoteRequest>
          <Symbol>SUNW</Symbol>
        </ns0:QuoteRequest>
      </env:Body>
    </env:Envelope>
    
  • And here is the secured SOAP message as it goes onto the wire:
  • <env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/" xmlns:enc="http://schemas.xmlsoap.org/soap/encoding/" xmlns:ns0="http://sun.com/stockquote.xsd" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
      <env:Header>
        <wsse:Security xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-01.xsd">
          <saml:Assertion xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion" AssertionID="s69f7e258e30da2b9b9f5799d4eb0c548782432bf" IssueInstant="2006-05-24T05:52:32Z" Issuer="patlinux" MajorVersion="1" MinorVersion="1">
            <saml:AuthenticationStatement AuthenticationInstant="2006-05-24T05:52:30Z" AuthenticationMethod="urn:com:sun:identity:Application">
              <saml:Subject>
                <saml:NameIdentifier>wsc</saml:NameIdentifier>
                <saml:SubjectConfirmation>
                  <saml:ConfirmationMethod>urn:oasis:names:tc:SAML:1.0:cm:holder-of-key</saml:ConfirmationMethod>
                  <KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
                    <KeyName>CN=patlinux, OU=Sun Java System Application Server, O=Sun Microsystems, L=Santa Clara, ST=California, C=US</KeyName>
                    <KeyValue>
                      <RSAKeyValue>
                       <Modulus>AIE1oq...</Modulus>
                       <Exponent>AQAB</Exponent>
                      </RSAKeyValue>
                    </KeyValue>
                  </KeyInfo>
                </saml:SubjectConfirmation>
              </saml:Subject>
            </saml:AuthenticationStatement>
            <Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
              <SignedInfo>
                <CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
                <SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
                <Reference URI="#s69f7e258e30da2b9b9f5799d4eb0c548782432bf">
                  <Transforms>
                    <Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
                    <Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
                  </Transforms>
                  <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
                  <DigestValue>zdCY/1iqOMUJq/RvxsaDPWM4+7c=</DigestValue>
                </Reference>
              </SignedInfo>
              <SignatureValue>ApcX/D...</SignatureValue>
              <KeyInfo>
                <X509Data>
                  <X509Certificate>MIICmj...</X509Certificate>
                </X509Data>
              </KeyInfo>
            </Signature>
          </saml:Assertion>
          <Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
            <SignedInfo>
              <CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
              <SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
              <Reference URI="#se0ffabd98ecfdf194adc0c8ac8fb4edabf65cd3a">
                <Transforms>
                  <Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
                </Transforms>
                <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
                <DigestValue>Sccy9a3A7Ps27f3pf9adkRWuGvU=</DigestValue>
              </Reference>
            </SignedInfo>
            <SignatureValue>aE9vKM...</SignatureValue>
            <KeyInfo>
              <SecurityTokenReference xmlns="http://schemas.xmlsoap.org/ws/2003/06/secext" wsu:Id="STR1">
                <KeyIdentifier ValueType="http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.0#SAMLAssertionID" wsu:Id="sbee70b80d8b330875655b8956d13ff5a4199ca1d">s69f7e258e30da2b9b9f5799d4eb0c548782432bf</KeyIdentifier>
              </SecurityTokenReference>
            </KeyInfo>
          </Signature>
        </wsse:Security>
      </env:Header>
      <env:Body wsu:Id="se0ffabd98ecfdf194adc0c8ac8fb4edabf65cd3a">
        <ns0:QuoteRequest>
          <Symbol>SUNW</Symbol>
        </ns0:QuoteRequest>
      </env:Body>
    </env:Envelope>
    

So - in the next thrilling installment, we'll walk through that secure SOAP message and see what each bit actually does.

UPDATE - here is that next installment.

Tuesday Apr 25, 2006

Welcome... To the blog world.

You have to imagine the title in a Morpheus voice. Anyway - welcome, Eric Leach, to the blogosphere. I guess this is going to turn into another 'great people I work with at Sun' post now

Eric is Product Line Manager for Federated Identity Management here at Sun, which kind of sounds like a tongue twister, but it is his real job, honest. Eric takes the customer requirements, engineering's hare-brained schemes, the specifications and standards appearing from various august (or not) bodies and, somehow, magically, orchestrates the production of Access Manager, Federation Manager and OpenSSO.

Yup - Eric is just about the busiest guy I know. Go read his thoughts, and leave lots of comments. Eric really needs the notification email to fill out his inbox. Honest

Thursday Apr 06, 2006

Customer Sabotage - Just What You Need in a Proof of Concept!

We conducted a proof-of-concept this week for a 'major manufacturer' (let's call them MM for short), showing Access Manager integrating with Active Directory Federation Services (ADFS) via WS-Federation. Briefly, the mechanism is that you attempt to access a protected resource and, if you don't have Access Manager's SSO token (as a cookie), you are redirected to ADFS for authentication. ADFS authenticates you then sends a SAML assertion back to a servlet at Access Manager via the HTML form POST/Javascript/onLoad trick\*. The servlet validates the SAML assertion and, if all is well, issues an Access Manager SSO token as a cookie and redirects back to the originally requested resource and all proceeds according to the regular Access Manager logic. The neat thing is that, if you're logged into a Windows domain, ADFS can authenticate you without any interaction, so all of the above magically happens in the blink of an eye, and you get the resource you asked for according to the AM policy in force. Kind of like the SPNEGO we all know and love, but all at a higher level, so it works better in large, complex multi-forest environments.

So - we get this all working (I'm remote at Sun's offices in Santa Clara, the PoC is at - uh - a secret location) and everyone there breaks for lunch. After lunch I get a slightly panicky call from the SE onsite (Hi, Bob!) saying that, inexplicably, it's no longer working. The browser isn't being forwarded to ADFS via AM's WS-Fed servlet - it's just going to the regular AM login page instead. Weird. I tail -f the logs, have them try again, and sure enough, the WS-Fed servlet is unmolested by traffic. I turn on the debug flag on the agent, tail -f the logs again and have them click the link. Whah!? The agent on the protected web server is redirecting to the CDSSO servlet? Why? A glance in the agent config shows that, somehow, magically, CDSSO has been enabled.

As Bob and I try to figure out just what has happened, I hear a voice in the background saying something like "Uh - Oh - Um". One of MM's senior technical staff is ex-Sun. He's had a little tinker over lunch, applying his AM knowledge and trying one or two things out. And left CDSSO enabled. Which tells the agent to redirect to the CDSSO servlet instead of my nifty new WS-Federation servlet. s/true/false/ on the 'enable CDSSO' property and all is working again. Phew!

Moral of the story. Never leave the customer alone in the PoC room with a logged in machine. Especially if they know enough to be dangerous!

\* In case you don't know this one, it goes like this. Server A returns an HTML page with a form containing one or more hidden elements - one might be, for instance, an XML document - and whose action is to POST to Server B. The page also contains a JavaScript onLoad event handler that submits the form. The result is a little like a 302 redirect, except that you get to send a bunch more data than you can cram into a URL.

Saturday Jan 21, 2006

Configuring Solaris to Authenticate against a Sun Java System Access Manager's Directory Server

Solaris (and other \*nix operating systems) can authenticate users against an LDAP compliant directory server, such as Sun Java System Directory Server, for log in. Sun Java System Access Manager can also authenticate users against an LDAP directory server for web single sign-on, access control and federation. There is an issue in that, by default, Access Manager locks down its Directory Server instance, removing the capability to do anonymous LDAP search and read operations. Unfortunately, this removes the ability for Solaris to authenticate users.

Jeff Nester, a Senior Identity Management Specialist at inSolutions (Dig the retro iPlanet favicon at inSolutions.net, Jeff!) recently wrote a paper explaining how to configure Directory Server and Access Manager so that Solaris and AM authentication co-exist. This allows you to create a single directory entry that enables access to both Solaris and web applications protected by AM.

Useful stuff if you're trying to consolidate directories and keep passwords consistent across desktop login and web applications. Lots of other goodies at Jeff's site too - must try the tips for getting a video projector to work on a Toshiba Tecra M2 in Java Desktop System. If that works, I definitely owe you a beer, Jeff

Wednesday Aug 10, 2005

Interested in working on the next generation of identity management at Sun?

Access Manager is hiring! We are looking for software engineers with 3-5 years experience in Java, J2EE and servlets to join the AM engineering team at Sun's Santa Clara campus. You can read through my blog to get an idea of some of the technologies used in Access Manager - web services, identity federation, kerberos - you might even get to work on the OpenSSO project.
If this sounds like you, then see the job specs here and here. Oh - and tell them Pat sent you
About

superpat

Search

Archives
« April 2014
MonTueWedThuFriSatSun
 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
    
       
Today