Custom kerberos auth scheme

[paulp13]

Has anyone developed a SiteMinder custom auth scheme that handles kerberos authentication?  If so can you provide any guidance (documentation, etc) or code examples?

 

So far I have been unable to find anything in the SiteMinder documentation.

[boatguypat]

Any chance of upgrading to the current release? There is a new Kerberos auth scheme included. How To Configure Kerberos Authentication - CA SiteMinder® - 12.52 SP1 - CA Wiki

[SungHoon_Kim]

Hi, The "How To Configure Kerberos Authentication" from CA Wiki site is a good start as recommended by obrpa06.

 

I have my own version here too. https://communities.ca.com/docs/DOC-231151618

And I am also preparing a Part 2 which includes Web Agent running on RHEL6.

 

Please take a look at the CA Wiki and also my technote(pre-release) and share your thoughts if they were helpful or if there could be improved.

 

Cheers,

 

Kim

[Chris Bertagnolli]

I work with mr. paulp13. Using the standard authentication scheme is fine if you don't want anything custom. In this case, the functionality attempting to be implemented for Kerberos authentication is not currently supported by SiteMinder auth schemes. Kerberos authentication itself is working ok with the provided methods, just can't do things like Authentication Mechanism Assurance (AMA).

 

So in this case we are exploring using a custom authentication scheme so that we can develop new functionality ourselves. Step 1 is just trying to get a Kerberos custom auth scheme going with nothing special/fancy. However, the SiteMinder development documentation is a little lacking and haven't had much luck finding specifics for Kerberos + SiteMinder.

[Legacy User]

Meanwhile has this been added as an Enhancement Request to the Product? Any means to tighten security is a good enhancement to have in a product.

 

Regards

 

Hubert.

[Chris Bertagnolli]

Yeah, it was submitted as an enhancement quite a while back in Mar 2014 (Authentication Level from Kerberos Ticket). But currently no idea where it is or if/when it would ever be implemented. Because of that unknown, looking at customizing authentication schemes to do what is needed if possible.

 

ADFS can do AMA natively but that means extra infrastructure and application(s) to maintain and still requiring customization in order to process the SAML response and set the appropriate session; and the investment into CA software already made that support Kerberos, SAML, WS-Fed etc so better to have it in one spot. So if it can be worked into CA SSO (can' we still call it SiteMinder???) either through custom auth scheme or enhancement implemented is definitely much better.

 

For internal/domain users it's definitely a big benefit since they get their seamless Kerberos SSO but the applications can still strictly enforce higher levels of authentication. It's also becoming even more important for Federated relationships where you want to ensure the user has authenticated at appropriate levels; E.g., TSCP Profile relies on not just knowing it is "Kerberos" but the level of that based on how the user authenticated to the desktop (medium hardware, one time password, etc).

[Chris Bertagnolli]

So here's a thought....No clue if it'd work or not and definitely not sure if it could be done securely.

 

IIS can natively enforce Authentication Mechanism Assurance as well. So if there was an ASPX or other page protected by IIS + AMA which would pass-through the user security context....Would it be possible to just take that user context, pass it down to the Policy Server, authenticate that user (no actual 'credential'), and do normal SM flow that way?

 

In that scenario, SiteMinder would just have to be able to securely receive the user context from a specific agent/form/whatever only; i.e., don't just take any context passed to it by anyone.

 

Any ideas if something like that would even be possible? Seems like that would offload a lot of the heavy lifting off SiteMinder -- much the way SiteMinder already relies on the Web Server to verify certificate key exchanges for X.509 (since that scheme literally accepts any public certificate and 'authenticates' it).