Symantec Access Management

I'm trying to figure out how we can create a SAML Auth scheme for smart card authentication independent of the directory that's used for user disambiguation.

On the same policy server, I'd like to use one SAML 1.1 Auth Scheme for issuing a SiteMinder session based solely on the federation trust, then use that session to disambiguate users in different domains associated with different user stores (each user store identifying the user by the card ID).

So the SAML 1.1. Auth scheme collects the card ID and creates a session on that card ID, then that session is used to create a new session based on directory 1 or directory 2 (depending on what realm is hit).

Does that make any sense?

What stumps me is how

1) I create a SAML 1.1. Auth scheme that is not associated with a local directory.
2) How I create the second session based on the SAML auth schem.

Any ideas?

Cheers,

Ryan

Hi All,

Any ideas here for Ryan?

Thanks!
Chris

Hey Ryan,

I seems to have missed out on some federation action this week so far :)!

Thanks Chris for helping us keep in the loop as always and for encouraging us!

Ok, so now coming to the actual use case, the way I think I understood is that SMFSS (SiteMinder Federation Security Services) is acting as a SAML 1.1 Consumer and therefore is consuming a SAML 1.1 Assertion for a user and SmartCard ID is received as part of the assertion and that needs to be used to get user authenticated into this other realm protected by let's say some smartcard authscheme. Few points that come to mind:

1) SAML 1.1 authscheme can in fact do the customized disambiguation and authentication of the user, using the MessgaeConsumer Plug-in (MCP).
2) I also thought about the Security Zones if it is just about being able to trust the SAML 1.1 authscheme created session into this other domain/realm but I think it is about being able to disambiguate the user in the other user store using the retrieved CardID from the assertion.
3) If the actual card id value from the assertion needs to be preserved and used to disambiguate the users in this other realm, we would need to get the value out and either persist it or set it as a header so that it can be retrieved for the auth into the other realm.


I think we may need to talk little more on this, so please reply and clear up for me please.

Specific Questions:

1) Realm1 is protected by SAML 1.1 auth-scheme, and Realm2 that needs to utilize the CardID received from the assertion, is protected by which auth-schme?
2) I think there is more to this use case or it seems like and I think if I can get little more understanding around the objective or the high level use case, it would be helpful for me to come up with few possible ways

Thanks,
---- Manjari.

Hi Manjari,

Thanks for responding :-). I think you've correctly understood the nature of the problem.

What I've got setup so far is similar to what you describe.

DummyDirectory is a dummy ODBC directory selecting from DUAL
CardDirectory is the real ODBC directory that relates the user to the card ID

The website domain uses DummyDirectory, but is authorized using a directory mapping to CardDirectory.

The website realm has an auth scheme pointing to our central (unprotected) federation launcher
mysite.domain.org -> logon.domain.org/fedLaunch.cgi?partner=cardprovider

The launcher stores the target in a cookie and redirects to the card provider producer federation partner -
-> cardprovider.com/domain.org/saml11producer?consumer=fss.domain.org/affwebservices/public/samlcc?target=fss.domain.org/cardprovider/redirect.html

There is a single domain using DummyDirectory for fss.domain.org and logon.domain.org.

/cardprovider/redirect.html is protected by the SAML11 auth scheme
- using the DummyDirectory with namespace ODBC,
- using an MCP postDisambiguateUser returning the card ID,
- and authorized using a very odd select from dual

redirect.html passes the user to central federation landing page
fss.domain.org/cardprovider/fedLanding.cgi

fss.domain.org/cardprovider/fedLanding.cgi is protected by the original auth scheme and pulls the target out of the cookie and redirects the user back to the original website.

It doesn't quite work... on the redirect.html I get "User is trying to access a resource protected with federation auth scheme without fed auth scheme credentials. No way to challange the user."

The use of the dummy directory seems wrong though.

Cheers,

Ryan

Another analyst here got a different solution working, but with a bit more complexity. I don't know the details, only a summary. It corresponds to your other thought.

Session 1 is created based on a SAML 11 auth scheme mapped to a single user in an LDAP directory. The cardid is in an attribute in the session store.

This auth scheme protects an FCC for the other session. A policy response sets user=cardid using smfedattrresponse.getAttributeValue. Since FCC's are generic across the organization, it also injects a security token as the password that is compared with the the card id in the auth scheme (not sure how it does this yet as I haven't seen it).

An update on this problem.

Part of the complexity of the problem is that we're dealing with two different bugs.

1) SAML11 to ODBC binding is broken if the bind field contains an "=". Ours does.
2) The UI refuses multiple SAML auth schemes with the same issuer.

We've worked around (2) by creating a perl script using the Policy Management API, so we've shifted gears to bind the SAML 11 auth scheme directly to the end directory.

This works, but requires a workaround for (1) that short circuits the MCP postDisambiguateUser to always return SUCCESS -

    public int postDisambiguateUser(APIContext  apiContext,
                                UserContext     userContext,
                                String          parameters,
                                String          message,
                                Map             props,
                                String          loginID,
                                final StringBuffer output
                                ) throws Exception {
        if ( !userContext.isUserContext() )
        {
          output.append(loginID);
        }
        return SUCCESS;
    }

The problem with this scheme is that if the user really doesn't exist in the directory, the validate on the target fails.

This is fine, but there's no authreasoncode handling. And I can't find where to handle a on validate user not found event.

Any ideas?