Amazon Aurora database supports external authentication of database users using Kerberos and Microsoft Active Directory.
Has anyone tested or implemented Single SignOn (SSO) integration between ForgeRock and Aurora database?
The intent is to have the end-user authenticate to ForgeRock and then connect to Aurora database (vis SSO) to execute queries.
Hi @ramesses - ForgeRock Access Management is not a ticket granting service in the world of Kerberos. AM can accept tickets as a means of authenticating a user, but it does not grant tickets that can be used by other applications (like Aurora). I’m not sure if Aurora accepts any other standards based methods for authenticating a user, but if they do there is a chance AM supports it as their standards support is very strong.
Hi @mwtech
Thank You for your response!
The approach we’re thinking is for the Windows Domain Controller to grant the tickets. We’re thinking of integrating ForgeRock to enable Windows Domain SSO, so that users don’t have to reauthenticate to ForgeRock if they are already signed on their Windows desktop.
Then we’re hoping ForgeRock can pass the Kerberos ticket to Aurora, so that the user can access Aurora. We would integrate Aurora as the Relying Party to ForgeRock as the Identity Provider.
I am attaching a figure to illustrate.
Will this approach work, or has this been tested/implemented with AWS Aurora? We didn’t find any documentation about such an integration.
AWS Aurora supports Kerberos and/or AWS IAM authentication. ( Using Kerberos authentication with Aurora PostgreSQL - Amazon Aurora)
Hi @ramesses - I can’t speak to whether or not anyone has tried this out, but I don’t see how it could work in ForgeRock as ForgeRock does not play the role of a ticket granting server. I’m also not sure why you would need ForgeRock to play that role as you already have your domain controller in that role. I’m not sure I understand why ForgeRock needs to be involved in this integration.
Hi @mwtech
Thank You for the quick response !
Based on the figure I attached in my previous post, are you interpreting that ForgeRock is being deployed as the ticket granting server, or would that be the Windows Domain Controller? The way I am looking at it, ForgeRock would facilitate the interactions, by passing the Kerberos ticket to the Relying Party (Aurora). I believe ForgeRock would receive the Kerberos ticket from the Windows Domain Controller.
Please correct me if my understanding above is incorrect.
In addition, I think you are also saying that ForgeRock may work in this scenario, but is redundant and may not be providing value. Is my understanding correct?
Thank You!
I am saying I don’t see what role ForgeRock would or could play in this interaction. The Kerberos ticket is not granted by ForgeRock, it is granted by the Windows Domain Controller, so it wouldn’t make sense that Aurora would attempt to retrieve the ticket from ForgeRock.
Hi @ramesses, Once ForgeRock AM receives a valid Kerberos token it generates and provides an SSO auth token as the ultimate result, rather than simply passing along the Kerberos token.
You may find the following article particularly helpful in clarifying the access flow:https://backstage.forgerock.com/knowledge/kb/article/a14556843#CBNLTV
I hope you find this information provides further insights into understanding the access flow in more detail.
Cheers,
Sheila
@salbertelli01
Thank You for your responses, they were helpful!
I read through the link you shared with me. From reading through the section about Kerberos flow in a federated environment - it seems to me that the client as well as the Service Provider (AWS Aurora) would automatically reach out to the ticket granting authority (in this case - the Windows Domain Controller) to request/retrieve the Kerberos token. And that adding ForgeRock IAM into the mix would not work (aside from being redundant).
Is my understanding above, correct?
Thank You!
Hi @ramesses,
Yes, your understanding is correct. In a federated environment using Kerberos, both the client and AWS Aurora can request Kerberos tokens from the Windows Domain Controller for authentication. However, it’s important to note that AM doesn’t issue Kerberos tickets.
In the SSO flow, obtaining a valid Kerberos token is an integral part of the initial transaction. This is done to authenticate to ForgeRock Access Management (AM) in a Single Sign-On (SSO) flow. To authenticate to AM without the need to provide login information again, a user must first present a valid Kerberos token to AM through the Simple and Protected GSS-API Negotiation Mechanism (SPNEGO) protocol.
I hope this helps to clarify further. It goes back to what @mwtech mentioned previously, where ForgeRock does not grant the Kerberos ticket. The Windows Domain Controller grants it, so it wouldn’t make sense that Aurora would attempt to retrieve the ticket from ForgeRock.
Please let us know if this helps.
Cheers,
Sheila
