Absent Member.
Absent Member.
335 views

Question about NAM setup


We have SSO implemented with a web-based service in our initial dev
setup of NAM. I did a packet capture for our security team to make sure
it meets our security needs and architecture and something came up. This
packet capture is of my going to the service provider website and
selecting to login by SSO, it redirects to our server for a username and
password and back to the service provider where I logged into their
service. The security team tells me that in that packet capture the web
browser never hits the Access Gateway but that redirect mentioned goes
to the ID server. It is my understanding from the documentation that
when using SSO, the service provider will reach out to our NAM gateway
and the gateway will then reach out to our NAM ID server which will
verify a user against our identity store which is eDirectory, pass it
back to the gateway, and then to service provider. Am I correct in that
understanding of how it is supposed to work? It seems like we are
bypassing the gateway entirely. Perhaps I misconfigured something or
gave the wrong connection information to the service provider because I
thought the service provider should be going through the reverse proxy
on the gateway.


--
bobbintb
------------------------------------------------------------------------
bobbintb's Profile: https://forums.netiq.com/member.php?userid=5629
View this thread: https://forums.netiq.com/showthread.php?t=53388

0 Likes
7 Replies
Absent Member.
Absent Member.

bobbintb wrote:

>
> We have SSO implemented with a web-based service in our initial dev
> setup of NAM. I did a packet capture for our security team to make
> sure it meets our security needs and architecture and something came
> up. This packet capture is of my going to the service provider
> website and selecting to login by SSO, it redirects to our server for
> a username and password and back to the service provider where I
> logged into their service. The security team tells me that in that
> packet capture the web browser never hits the Access Gateway but that
> redirect mentioned goes to the ID server.


This is correct

> It is my understanding from
> the documentation that when using SSO, the service provider will
> reach out to our NAM gateway and the gateway will then reach out to
> our NAM ID server which will verify a user against our identity store
> which is eDirectory, pass it back to the gateway, and then to service
> provider. Am I correct in that understanding of how it is supposed to
> work?


Nope, it doesn't do that. All authentication is handled by the Identity
Providers. Even when you are using the access gateways except for when
you are using non-redirected logins which are a special contract you
can configure. If you use those then the AG will call the IDP to
validate credentials supplied.

> It seems like we are bypassing the gateway entirely. Perhaps I
> misconfigured something or gave the wrong connection information to
> the service provider because I thought the service provider should be
> going through the reverse proxy on the gateway.


Nothing is misconfigured. Eveything is working perfectly fine.


--
Cheers,
Edward
0 Likes
Absent Member.
Absent Member.


Since that's the case I guess I don't really understand what the purpose
of the gateway is then. We have a DMZ and the security team is trying to
ascertain what servers need to go where. How I previously understood it
I thought the gateway went in the DMZ but it sounds like the ID server
needs to. But if the client never touches the gateway, what is it's
function? Apparently I'm just not understanding what the documentation
is telling me.


--
bobbintb
------------------------------------------------------------------------
bobbintb's Profile: https://forums.netiq.com/member.php?userid=5629
View this thread: https://forums.netiq.com/showthread.php?t=53388

0 Likes
Absent Member.
Absent Member.

bobbintb wrote:

>
> Since that's the case I guess I don't really understand what the
> purpose of the gateway is then. We have a DMZ and the security team
> is trying to ascertain what servers need to go where. How I
> previously understood it I thought the gateway went in the DMZ but it
> sounds like the ID server needs to. But if the client never touches
> the gateway, what is it's function? Apparently I'm just not
> understanding what the documentation is telling me.


The gateway is the proxy component. If you protect a webserver through
NAM then all traffic for the web application goes through the gateway.
Authentication is handled by the Identity Provider.

--
Cheers,
Edward
0 Likes
Absent Member.
Absent Member.

bobbintb wrote :
> Since that's the case I guess I don't really understand what the purpose
> of the gateway is then. We have a DMZ and the security team is trying to
> ascertain what servers need to go where. How I previously understood it
> I thought the gateway went in the DMZ but it sounds like the ID server
> needs to. But if the client never touches the gateway, what is it's
> function? Apparently I'm just not understanding what the documentation
> is telling me.


FYI - There is a configuration that places your IDPs behind your AGs.
Documentation on how to set this up is here:
https://www.netiq.com/documentation/access-manager-41/install_upgrade/data/b8985pl.html

HTH,
Mike


0 Likes
Knowledge Partner Knowledge Partner
Knowledge Partner

bobbintb;2392125 wrote:
We have SSO implemented with a web-based service in our initial dev
setup of NAM. I did a packet capture for our security team to make sure
it meets our security needs and architecture and something came up. This
packet capture is of my going to the service provider website and
selecting to login by SSO, it redirects to our server for a username and
password and back to the service provider where I logged into their
service. The security team tells me that in that packet capture the web
browser never hits the Access Gateway but that redirect mentioned goes
to the ID server. It is my understanding from the documentation that
when using SSO, the service provider will reach out to our NAM gateway
and the gateway will then reach out to our NAM ID server which will
verify a user against our identity store which is eDirectory, pass it
back to the gateway, and then to service provider. Am I correct in that
understanding of how it is supposed to work? It seems like we are
bypassing the gateway entirely. Perhaps I misconfigured something or
gave the wrong connection information to the service provider because I
thought the service provider should be going through the reverse proxy
on the gateway.


--
bobbintb
------------------------------------------------------------------------
bobbintb's Profile: https://forums.netiq.com/member.php?userid=5629
View this thread: https://forums.netiq.com/showthread.php?t=53388


Depends on how your setup is and how you tested. IMO, normally this is what would happen:

If you have an AG defined resource as "protected", what *should* normally happen is that you enter (into your web browser) the URL of the AG resource. ie:
https://something.com

The Wireshark capture SHOULD show that a request is going to that IP and then the AG redirects your browser to your IDS server. You authenticate. Assuming successful authentication, your browser is then redirected BACK to the original requested URL (https://something.com) and the AG allows the request to complete and proxies the data to the origin web server.

However, if you hit the IDS server *first*, and login, then you're just authenticated and the IDS has no idea where you wanted to go to (you may have 30 protected resources in the AG). Unless you possibly setup ID cards with redirection or something, which (IMO) is overly-complicating things.

--Kevin
0 Likes
Absent Member.
Absent Member.

kjhurni wrote:


> Depends on how your setup is and how you tested. IMO, normally this
> is what would happen:
>
> If you have an AG defined resource as "protected", what should
> normally happen is that you enter (into your web browser) the URL of
> the AG resource. ie:
> https://something.com
>
> The Wireshark capture SHOULD show that a request is going to that IP
> and then the AG redirects your browser to your IDS server. You
> authenticate. Assuming successful authentication, your browser is
> then redirected BACK to the original requested URL
> (https://something.com) and the AG allows the request to complete and
> proxies the data to the origin web server.
>
> However, if you hit the IDS server first, and login, then you're just
> authenticated and the IDS has no idea where you wanted to go to (you
> may have 30 protected resources in the AG). Unless you possibly
> setup ID cards with redirection or something, which (IMO) is
> overly-complicating things.


It depends on how they implemented SSO. The OP might be using
federation (SAML/WS-Fed). In that case the AG is not used.


--
Cheers,
Edward
0 Likes
Knowledge Partner Knowledge Partner
Knowledge Partner

Edward van der Maas;2392296 wrote:
kjhurni wrote:


> Depends on how your setup is and how you tested. IMO, normally this
> is what would happen:
>
> If you have an AG defined resource as "protected", what should
> normally happen is that you enter (into your web browser) the URL of
> the AG resource. ie:
> https://something.com
>
> The Wireshark capture SHOULD show that a request is going to that IP
> and then the AG redirects your browser to your IDS server. You
> authenticate. Assuming successful authentication, your browser is
> then redirected BACK to the original requested URL
> (https://something.com) and the AG allows the request to complete and
> proxies the data to the origin web server.
>
> However, if you hit the IDS server first, and login, then you're just
> authenticated and the IDS has no idea where you wanted to go to (you
> may have 30 protected resources in the AG). Unless you possibly
> setup ID cards with redirection or something, which (IMO) is
> overly-complicating things.


It depends on how they implemented SSO. The OP might be using
federation (SAML/WS-Fed). In that case the AG is not used.


--
Cheers,
Edward


True, although if you have the origin web server "protected" even using SAML, if you hit the AG FIRST with your web browser, it'll still redirect. We have SAML in several spots and that's how it works for us.

Yes, you could login/access the IDS first, but we publish the URL of the AG "published' proxy so that the entire login process flows through and transparently redirects the user back to the original request so they don't have to mess with auth cards/etc.
0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.