Topic
  • 9 replies
  • Latest Post - ‏2014-04-02T14:40:02Z by Dave_Mo_Soleterra
Nrutas
Nrutas
17 Posts

Pinned topic DataPower - SiteMinder Integration

‏2012-01-25T10:50:47Z |
Hi,

As I understand CA SiteMinder can be used as an option to Autheticate / Authorize an user in the AAA Action within DataPower.

1. Does DataPower use the Host, Port and Base URI to connect to the SiteMinder Agent deployed in an Web Server ?
2. Is there a way to call SiteMinder directly via HTTP call ? Any reference on this will be helpful.

Thanks.
Updated on 2012-01-27T14:46:08Z at 2012-01-27T14:46:08Z by irazabal
  • HermannSW
    HermannSW
    4647 Posts

    Re: DataPower - SiteMinder Integration

    ‏2012-01-25T14:42:20Z  
    I have never done this, but please look for "Siteminder" in these Inforcenter pages:
    Authenticate Tab
    Defining the authorization method

     
    Hermann<myXsltBlog/>
  • irazabal
    irazabal
    218 Posts

    Re: DataPower - SiteMinder Integration

    ‏2012-01-25T18:40:21Z  
    Option 1 - HTTP GET to SiteMinder WebAgent - this involves making a "side" call from the DP box.

    This is the simplest option, both to configure and to execute. It uses the existing SiteMinder URL protections to perform authentication and authorization at any point in a DataPower service. This is the “standard” behavior when CA/Netegrity is selected in a AAA policy and no CA/Netegrity configuration object is defined.

    Pros: No additional code needs to be written. Existing SiteMinder configuration will continue to remain useful. All communication is done via standard protocols (HTTP GET). DataPower AAA policy configuration is a simple process. Follows a loosely-coupled model, so that authentication/authorization can be moved to another server/methodology at any point. Doesn’t need the libraries from CA/Netegrity to be built in our firmware.

    Cons: Simplistic AAA methodology that responds with a simple accept/reject answer. SiteMinder SMSession cookie responses are not retrieved for post-processing.

    Option 2: HTTP GET to Perl script that returns SMSession variables - this is a variation on option 3.

    This is similar to the option 3, but the authentication/authorization request is routed through a script running in a Perl environment (CGI directory on a web server). Cookie responses from the request are parsed into an XML format and returned to the DataPower device for further processing (if necessary). The script would be provided by DataPower; all other configuration would be SiteMinder standard.

    Pros: Simple DataPower configuration; instead of defining a SiteMinder WebAgent URL, the script URL is entered instead. All cookies returned by SiteMinder are available within DataPower for post-processing. Follows a loosely-coupled methodology for future AU/AZ replacement if desired.

    Cons: Configuration replacement options may be limited, as cookies may not be available using other methodologies. Requires Perl environment to be running on a web server.

    Option 3: Pass entire message/request to SiteMinder after AAA processing on the DP Appliance.

    This configuration is only used when SiteMinder is deeply architected into the Web Services security/routing architecture. Every request, after passing through the DataPower appliance, would be routed to SiteMinder for AAA and forwarding to the service endpoint.

    Pros: All Netegrity functions would be available, as SiteMinder would be dealing with all AAA tasks.

    Cons: Relies on a software-based solution for all AAA tasks. Would require two “hops” for every request. Architecture would be tightly-coupled to a single product and proprietary communications protocols and would be difficult to swap for another AU/AZ method.
  • irazabal
    irazabal
    218 Posts

    Re: DataPower - SiteMinder Integration

    ‏2012-01-25T18:41:34Z  
    Option 1 - HTTP GET to SiteMinder WebAgent - this involves making a "side" call from the DP box.

    This is the simplest option, both to configure and to execute. It uses the existing SiteMinder URL protections to perform authentication and authorization at any point in a DataPower service. This is the “standard” behavior when CA/Netegrity is selected in a AAA policy and no CA/Netegrity configuration object is defined.

    Pros: No additional code needs to be written. Existing SiteMinder configuration will continue to remain useful. All communication is done via standard protocols (HTTP GET). DataPower AAA policy configuration is a simple process. Follows a loosely-coupled model, so that authentication/authorization can be moved to another server/methodology at any point. Doesn’t need the libraries from CA/Netegrity to be built in our firmware.

    Cons: Simplistic AAA methodology that responds with a simple accept/reject answer. SiteMinder SMSession cookie responses are not retrieved for post-processing.

    Option 2: HTTP GET to Perl script that returns SMSession variables - this is a variation on option 3.

    This is similar to the option 3, but the authentication/authorization request is routed through a script running in a Perl environment (CGI directory on a web server). Cookie responses from the request are parsed into an XML format and returned to the DataPower device for further processing (if necessary). The script would be provided by DataPower; all other configuration would be SiteMinder standard.

    Pros: Simple DataPower configuration; instead of defining a SiteMinder WebAgent URL, the script URL is entered instead. All cookies returned by SiteMinder are available within DataPower for post-processing. Follows a loosely-coupled methodology for future AU/AZ replacement if desired.

    Cons: Configuration replacement options may be limited, as cookies may not be available using other methodologies. Requires Perl environment to be running on a web server.

    Option 3: Pass entire message/request to SiteMinder after AAA processing on the DP Appliance.

    This configuration is only used when SiteMinder is deeply architected into the Web Services security/routing architecture. Every request, after passing through the DataPower appliance, would be routed to SiteMinder for AAA and forwarding to the service endpoint.

    Pros: All Netegrity functions would be available, as SiteMinder would be dealing with all AAA tasks.

    Cons: Relies on a software-based solution for all AAA tasks. Would require two “hops” for every request. Architecture would be tightly-coupled to a single product and proprietary communications protocols and would be difficult to swap for another AU/AZ method.
  • Nrutas
    Nrutas
    17 Posts

    Re: DataPower - SiteMinder Integration

    ‏2012-01-27T07:35:21Z  
    • irazabal
    • ‏2012-01-25T18:41:34Z
    Option 1 - HTTP GET to SiteMinder WebAgent - this involves making a "side" call from the DP box.

    This is the simplest option, both to configure and to execute. It uses the existing SiteMinder URL protections to perform authentication and authorization at any point in a DataPower service. This is the “standard” behavior when CA/Netegrity is selected in a AAA policy and no CA/Netegrity configuration object is defined.

    Pros: No additional code needs to be written. Existing SiteMinder configuration will continue to remain useful. All communication is done via standard protocols (HTTP GET). DataPower AAA policy configuration is a simple process. Follows a loosely-coupled model, so that authentication/authorization can be moved to another server/methodology at any point. Doesn’t need the libraries from CA/Netegrity to be built in our firmware.

    Cons: Simplistic AAA methodology that responds with a simple accept/reject answer. SiteMinder SMSession cookie responses are not retrieved for post-processing.

    Option 2: HTTP GET to Perl script that returns SMSession variables - this is a variation on option 3.

    This is similar to the option 3, but the authentication/authorization request is routed through a script running in a Perl environment (CGI directory on a web server). Cookie responses from the request are parsed into an XML format and returned to the DataPower device for further processing (if necessary). The script would be provided by DataPower; all other configuration would be SiteMinder standard.

    Pros: Simple DataPower configuration; instead of defining a SiteMinder WebAgent URL, the script URL is entered instead. All cookies returned by SiteMinder are available within DataPower for post-processing. Follows a loosely-coupled methodology for future AU/AZ replacement if desired.

    Cons: Configuration replacement options may be limited, as cookies may not be available using other methodologies. Requires Perl environment to be running on a web server.

    Option 3: Pass entire message/request to SiteMinder after AAA processing on the DP Appliance.

    This configuration is only used when SiteMinder is deeply architected into the Web Services security/routing architecture. Every request, after passing through the DataPower appliance, would be routed to SiteMinder for AAA and forwarding to the service endpoint.

    Pros: All Netegrity functions would be available, as SiteMinder would be dealing with all AAA tasks.

    Cons: Relies on a software-based solution for all AAA tasks. Would require two “hops” for every request. Architecture would be tightly-coupled to a single product and proprietary communications protocols and would be difficult to swap for another AU/AZ method.
    Thank you Alex for your elaborate explanation on the topic.

    Since I would want to get back the SMSession cookies, I think 'Option 1' is not going to serve my purpose.

    For 'Option 2' what I understand is that DataPower needs to forward the request to a Perl Script running on a web server. The script would be responsible for returning the cookie responses. In that case does DataPower have any capability to cache the sessions which I might use to validate subsequent requests ? If not, is there any work around ?

    Thanks.
  • irazabal
    irazabal
    218 Posts

    Re: DataPower - SiteMinder Integration

    ‏2012-01-27T14:46:08Z  
    • Nrutas
    • ‏2012-01-27T07:35:21Z
    Thank you Alex for your elaborate explanation on the topic.

    Since I would want to get back the SMSession cookies, I think 'Option 1' is not going to serve my purpose.

    For 'Option 2' what I understand is that DataPower needs to forward the request to a Perl Script running on a web server. The script would be responsible for returning the cookie responses. In that case does DataPower have any capability to cache the sessions which I might use to validate subsequent requests ? If not, is there any work around ?

    Thanks.
    none that I can think of... you could cache them where the script resides and have it manage it ...but that would probably be clumsy. The only support we have directly from DP is direct authentication to SM w/o cookies (option 1).
  • HareeshKarakkal
    HareeshKarakkal
    1 Post

    Re: DataPower - SiteMinder Integration

    ‏2013-06-27T12:46:00Z  
    • irazabal
    • ‏2012-01-25T18:40:21Z
    Option 1 - HTTP GET to SiteMinder WebAgent - this involves making a "side" call from the DP box.

    This is the simplest option, both to configure and to execute. It uses the existing SiteMinder URL protections to perform authentication and authorization at any point in a DataPower service. This is the “standard” behavior when CA/Netegrity is selected in a AAA policy and no CA/Netegrity configuration object is defined.

    Pros: No additional code needs to be written. Existing SiteMinder configuration will continue to remain useful. All communication is done via standard protocols (HTTP GET). DataPower AAA policy configuration is a simple process. Follows a loosely-coupled model, so that authentication/authorization can be moved to another server/methodology at any point. Doesn’t need the libraries from CA/Netegrity to be built in our firmware.

    Cons: Simplistic AAA methodology that responds with a simple accept/reject answer. SiteMinder SMSession cookie responses are not retrieved for post-processing.

    Option 2: HTTP GET to Perl script that returns SMSession variables - this is a variation on option 3.

    This is similar to the option 3, but the authentication/authorization request is routed through a script running in a Perl environment (CGI directory on a web server). Cookie responses from the request are parsed into an XML format and returned to the DataPower device for further processing (if necessary). The script would be provided by DataPower; all other configuration would be SiteMinder standard.

    Pros: Simple DataPower configuration; instead of defining a SiteMinder WebAgent URL, the script URL is entered instead. All cookies returned by SiteMinder are available within DataPower for post-processing. Follows a loosely-coupled methodology for future AU/AZ replacement if desired.

    Cons: Configuration replacement options may be limited, as cookies may not be available using other methodologies. Requires Perl environment to be running on a web server.

    Option 3: Pass entire message/request to SiteMinder after AAA processing on the DP Appliance.

    This configuration is only used when SiteMinder is deeply architected into the Web Services security/routing architecture. Every request, after passing through the DataPower appliance, would be routed to SiteMinder for AAA and forwarding to the service endpoint.

    Pros: All Netegrity functions would be available, as SiteMinder would be dealing with all AAA tasks.

    Cons: Relies on a software-based solution for all AAA tasks. Would require two “hops” for every request. Architecture would be tightly-coupled to a single product and proprietary communications protocols and would be difficult to swap for another AU/AZ method.

    I am trying to implement Option1, do you have any document on this...

  • dave_mo
    dave_mo
    18 Posts

    Re: DataPower - SiteMinder Integration

    ‏2013-07-02T01:39:37Z  
    • irazabal
    • ‏2012-01-27T14:46:08Z
    none that I can think of... you could cache them where the script resides and have it manage it ...but that would probably be clumsy. The only support we have directly from DP is direct authentication to SM w/o cookies (option 1).

    Actually option 1 (using custom template instead of "Netegrity SiteMinder" selection) can return the SMSESSION as long as the url-open in your side call to the SiteMinder protected url uses responsecode or responsecode-ignore.  Part of the returned data (assuming the request was authenticated and authorized in SiteMinder) are headers.  Via code, first I'd check that the status code is 200 not 401 (assuming you are using basic auth with SiteMinder).  If 200, you can grab the Set-Cookie header where the value starts-with SMSESSION=.......  and grab the value after SMSESSION=.  Check infocenter for url-open.  Option 2 is unnecessary if you use a custom stylesheet for the side call with url-open.  You'll see in the case of responsecode-ignore, the returned data would look like:

     

    
    <url-open>  <statuscode>0</statuscode>  <responsecode>0</responsecode>  <errorcode>0</errorcode>  <errorstring>error</errorstring>  <contenttype>text/xml</contenttype>  <headers>    <header name="contenttype">text/xml</header>      ...    <header name="foo">bar</header>  </headers></url-open>
    

     

    I've tested this out and am able to get the Set-Cookie header value where SMSESSION=.

     

    What is not clear to me is why you'd want to cache the SMSESSION.  Don't forget that depending on your realm settings, you might have either max timeout or idle session timeout defined.  This would cause havoc if the session expires since you'd have to handle reauthenticating to SM to get a new SMSESSION.  While caching the sessions is possible, the cost outweighs the benefits in my opinion.  I can explain how the caching would work if interested but I think caching those sessions is a bad idea.

     

    UPDATE: Sorry for replying to such an old thread.  I look at the forum a couple times a week to see new threads.  Some how, this thread showed up in the last couple of days and I responded.  Afterwards, I reviewed the dates in the replies and realized how old they were.  Not sure why this thread showed up in todays.  Also, I wish wish wish we had the old Searching back.  This forum was so valuable, but without the search working like search should, its been very hard to use to find topics related to something I might want to find.

    Updated on 2013-07-02T02:17:20Z at 2013-07-02T02:17:20Z by dave_mo
  • mefeai
    mefeai
    8 Posts

    Re: DataPower - SiteMinder Integration

    ‏2014-02-21T17:43:04Z  
    • dave_mo
    • ‏2013-07-02T01:39:37Z

    Actually option 1 (using custom template instead of "Netegrity SiteMinder" selection) can return the SMSESSION as long as the url-open in your side call to the SiteMinder protected url uses responsecode or responsecode-ignore.  Part of the returned data (assuming the request was authenticated and authorized in SiteMinder) are headers.  Via code, first I'd check that the status code is 200 not 401 (assuming you are using basic auth with SiteMinder).  If 200, you can grab the Set-Cookie header where the value starts-with SMSESSION=.......  and grab the value after SMSESSION=.  Check infocenter for url-open.  Option 2 is unnecessary if you use a custom stylesheet for the side call with url-open.  You'll see in the case of responsecode-ignore, the returned data would look like:

     

    <pre class="xmp" dir="ltr" style="color: rgb(0, 0, 0);"> <url-open> <statuscode>0</statuscode> <responsecode>0</responsecode> <errorcode>0</errorcode> <errorstring>error</errorstring> <contenttype>text/xml</contenttype> <headers> <header name="contenttype">text/xml</header> ... <header name="foo">bar</header> </headers></url-open> </pre>

     

    I've tested this out and am able to get the Set-Cookie header value where SMSESSION=.

     

    What is not clear to me is why you'd want to cache the SMSESSION.  Don't forget that depending on your realm settings, you might have either max timeout or idle session timeout defined.  This would cause havoc if the session expires since you'd have to handle reauthenticating to SM to get a new SMSESSION.  While caching the sessions is possible, the cost outweighs the benefits in my opinion.  I can explain how the caching would work if interested but I think caching those sessions is a bad idea.

     

    UPDATE: Sorry for replying to such an old thread.  I look at the forum a couple times a week to see new threads.  Some how, this thread showed up in the last couple of days and I responded.  Afterwards, I reviewed the dates in the replies and realized how old they were.  Not sure why this thread showed up in todays.  Also, I wish wish wish we had the old Searching back.  This forum was so valuable, but without the search working like search should, its been very hard to use to find topics related to something I might want to find.

    Hello There.

    I am trying to do something similar which is not working. I have to connect to a RESTful Service which is protected over siteminder through BASIC AUTH. When i put the URL in my browser it comes up with a USERID/PASSWD challenge. Upon entering the credentials it gives me the desired result. When i do the same in Datapower via dp-openurl, it gives me a HTTP 403 . When we check the Headers from a browser REST Client we see that the SMSession cookie gets populated after it has passed Siteminder. How do i get this to work in Datapower so the redirect happens seemless. Should a MPG be used instead of a XML Firewall. Please let me know

    Thanks,

  • Dave_Mo_Soleterra
    Dave_Mo_Soleterra
    5 Posts

    Re: DataPower - SiteMinder Integration

    ‏2014-04-02T14:40:02Z  
    • mefeai
    • ‏2014-02-21T17:43:04Z

    Hello There.

    I am trying to do something similar which is not working. I have to connect to a RESTful Service which is protected over siteminder through BASIC AUTH. When i put the URL in my browser it comes up with a USERID/PASSWD challenge. Upon entering the credentials it gives me the desired result. When i do the same in Datapower via dp-openurl, it gives me a HTTP 403 . When we check the Headers from a browser REST Client we see that the SMSession cookie gets populated after it has passed Siteminder. How do i get this to work in Datapower so the redirect happens seemless. Should a MPG be used instead of a XML Firewall. Please let me know

    Thanks,

    Assuming you are adding the credentials to the Basic Auth header correctly via the url-open, then SiteMinder might be throwing the 403 because it requires the user to support cookies by default.  Try setting RequireCookies=no in the ACO for that agent.