Guidance

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Guidance

Rife, Brandon
Hello All,

I’m looking for some high level guidance on how to go about protecting REST web service calls.

The scenario is as follows. The user agent will log into a web application that is protected by OpenAM and the web application will be calling REST web services on behalf of the authenticated user.  I want the REST web service to be able to verify that that the caller is authenticated and that the caller has the necessary permissions to evoke a particular end point.  How can I leverage the fact that OpenAM is already protecting the web application that is making the calls on behalf of the user?

Thanks!

________________________________

NOTICE: This e-mail and any attachments is intended only for use by the addressee(s) named herein and may contain legally privileged, proprietary or confidential information. If you are not the intended recipient of this e-mail, you are hereby notified that any dissemination, distribution or copying of this email, and any attachments thereto, is strictly prohibited. If you receive this email in error please immediately notify me via reply email or at (800) 927-9800 and permanently delete the original copy and any copy of any e-mail, and any printout.
_______________________________________________
Visit the OpenAM forum at https://forgerock.org/forum/fr-projects/openam/
OpenAM mailing list
[hidden email]
https://lists.forgerock.org/mailman/listinfo/openam
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Guidance

Simon Moffatt

Hi Brandon

Really depends on how the REST API is being protected...

You could simply pass the iPlanet cookie into the REST API from your calling web application and let the API programmatically call OpenAM to check the cookie/tokenId validity, retrieve any attributes needed to check any necessary authZ or call the OpenAM policy engine over it's own REST endpoint to check if the user should have access to your API.

Simon


On 30/08/16 17:34, Rife, Brandon wrote:
Hello All,

I’m looking for some high level guidance on how to go about protecting REST web service calls.

The scenario is as follows. The user agent will log into a web application that is protected by OpenAM and the web application will be calling REST web services on behalf of the authenticated user.  I want the REST web service to be able to verify that that the caller is authenticated and that the caller has the necessary permissions to evoke a particular end point.  How can I leverage the fact that OpenAM is already protecting the web application that is making the calls on behalf of the user?

Thanks!

________________________________

NOTICE: This e-mail and any attachments is intended only for use by the addressee(s) named herein and may contain legally privileged, proprietary or confidential information. If you are not the intended recipient of this e-mail, you are hereby notified that any dissemination, distribution or copying of this email, and any attachments thereto, is strictly prohibited. If you receive this email in error please immediately notify me via reply email or at (800) 927-9800 and permanently delete the original copy and any copy of any e-mail, and any printout.
_______________________________________________
Visit the OpenAM forum at https://forgerock.org/forum/fr-projects/openam/
OpenAM mailing list
[hidden email]
https://lists.forgerock.org/mailman/listinfo/openam

--
ForgeRock Simon Moffatt
Advanced Customer Engineering  |  ForgeRock
tel +44 (0) 7903 347 240  |  e [hidden email]
skype simon.moffatt  |  web www.forgerock.com  |  twitter @simonmoffatt


Summits

_______________________________________________
Visit the OpenAM forum at https://forgerock.org/forum/fr-projects/openam/
OpenAM mailing list
[hidden email]
https://lists.forgerock.org/mailman/listinfo/openam
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Guidance

Christian Viola
Hi Brandon,

Your use-case has written OAuth2 all over it - access delegation.

In principle - and thats the way we approach this too - you have the end user login via a web application of some sort, and pass the token you retrieve from OpenAm (Authorization Server) down to the REST endpoints you are planing to protect (Resource Server). In the most recent release 13.5 OpenAM allows for stateless OAuth2 Tokens putting less strain on the tokeninfo endpoint.

You can even have a REST API retrieve a token for itself and pass that down to another REST API. The permissions you spoke of, would be scopes (arbitrary strings) and they can be assigned to an individual user. Once the token is evaluated by the REST API appropriate access controls can be applied based on these scopes.

Hope that helped.

Best
/Chris

IAM Engineer | Zalando SE | Berlin Germany



On 30 August 2016 at 19:54, Simon Moffatt <[hidden email]> wrote:

Hi Brandon

Really depends on how the REST API is being protected...

You could simply pass the iPlanet cookie into the REST API from your calling web application and let the API programmatically call OpenAM to check the cookie/tokenId validity, retrieve any attributes needed to check any necessary authZ or call the OpenAM policy engine over it's own REST endpoint to check if the user should have access to your API.

Simon


On 30/08/16 17:34, Rife, Brandon wrote:
Hello All,

I’m looking for some high level guidance on how to go about protecting REST web service calls.

The scenario is as follows. The user agent will log into a web application that is protected by OpenAM and the web application will be calling REST web services on behalf of the authenticated user.  I want the REST web service to be able to verify that that the caller is authenticated and that the caller has the necessary permissions to evoke a particular end point.  How can I leverage the fact that OpenAM is already protecting the web application that is making the calls on behalf of the user?

Thanks!

________________________________

NOTICE: This e-mail and any attachments is intended only for use by the addressee(s) named herein and may contain legally privileged, proprietary or confidential information. If you are not the intended recipient of this e-mail, you are hereby notified that any dissemination, distribution or copying of this email, and any attachments thereto, is strictly prohibited. If you receive this email in error please immediately notify me via reply email or at <a href="tel:%28800%29%20927-9800" value="+18009279800" target="_blank">(800) 927-9800 and permanently delete the original copy and any copy of any e-mail, and any printout.
_______________________________________________
Visit the OpenAM forum at https://forgerock.org/forum/fr-projects/openam/
OpenAM mailing list
[hidden email]
https://lists.forgerock.org/mailman/listinfo/openam

--
ForgeRock Simon Moffatt
Advanced Customer Engineering  |  ForgeRock
tel <a href="tel:%2B44%20%280%29%207903%20347%20240" value="+447903347240" target="_blank">+44 (0) 7903 347 240  |  e [hidden email]
skype simon.moffatt  |  web www.forgerock.com  |  twitter @simonmoffatt


Summits

_______________________________________________
Visit the OpenAM forum at https://forgerock.org/forum/fr-projects/openam/
OpenAM mailing list
[hidden email]
https://lists.forgerock.org/mailman/listinfo/openam



_______________________________________________
Visit the OpenAM forum at https://forgerock.org/forum/fr-projects/openam/
OpenAM mailing list
[hidden email]
https://lists.forgerock.org/mailman/listinfo/openam
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Guidance

Paul Figura
In reply to this post by Rife, Brandon

Hi Brandon,

there are many different ways to accomplish what you are trying to do. Someone else mentioned Oauth2 (which is a valid usecase), but in addition to that, if you want to do things directly in your application, you have a lot of options:

  • Using Web Agents to protect certain URLS of your application based on application policies, preventing execution of certain rest calls entirely (you probably already do this).
  • Leveraging the OpenAM session cookie to make all calls to your REST web service. Your Web service can then make a session validation for each call directly to OpenAM to validate the user session, and extract uid.
  • Utilizing the OpenAM STS to issue tokens for each request, which can be inserted into the request for cryptographic security (though these tokens are typically SAML, and you didn't ask about that)
  • Creating a custom REST endpoint inside OpenAM which can do whatever logic your application would need.
  • Leveraging OpenIG to protect your rest services
  • Probably others!

We've done a lot of these integration's before, and it's really dependent on your requirements. Though you're really not limited by OpenAM, limitations usually will come from business constraints :)

Regards,
Paul Figura
Identity & Access Management Architect
Indigo Consulting Canada
Tel: 514-432-6233
Email: [hidden email]  http://www.indigoconsulting.ca
   
On 8/30/2016 12:34 PM, Rife, Brandon wrote:
Hello All,

I’m looking for some high level guidance on how to go about protecting REST web service calls.

The scenario is as follows. The user agent will log into a web application that is protected by OpenAM and the web application will be calling REST web services on behalf of the authenticated user.  I want the REST web service to be able to verify that that the caller is authenticated and that the caller has the necessary permissions to evoke a particular end point.  How can I leverage the fact that OpenAM is already protecting the web application that is making the calls on behalf of the user?

Thanks!

________________________________

NOTICE: This e-mail and any attachments is intended only for use by the addressee(s) named herein and may contain legally privileged, proprietary or confidential information. If you are not the intended recipient of this e-mail, you are hereby notified that any dissemination, distribution or copying of this email, and any attachments thereto, is strictly prohibited. If you receive this email in error please immediately notify me via reply email or at (800) 927-9800 and permanently delete the original copy and any copy of any e-mail, and any printout.
_______________________________________________
Visit the OpenAM forum at https://forgerock.org/forum/fr-projects/openam/
OpenAM mailing list
[hidden email]
https://lists.forgerock.org/mailman/listinfo/openam


_______________________________________________
Visit the OpenAM forum at https://forgerock.org/forum/fr-projects/openam/
OpenAM mailing list
[hidden email]
https://lists.forgerock.org/mailman/listinfo/openam
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Guidance

Rife, Brandon
In reply to this post by Christian Viola
Thanks, Chris.  That’s the conclusion that I was getting from reading the OAuth2 and OpenID info in the OpenAM Admin guide.

From: <[hidden email]> on behalf of Christian Viola <[hidden email]>
Reply-To: Users <[hidden email]>
Date: Wednesday, August 31, 2016 at 1:52 AM
To: Users <[hidden email]>
Subject: Re: [OpenAM] Guidance

Hi Brandon,
Your use-case has written OAuth2 all over it - access delegation.

In principle - and thats the way we approach this too - you have the end user login via a web application of some sort, and pass the token you retrieve from OpenAm (Authorization Server) down to the REST endpoints you are planing to protect (Resource Server). In the most recent release 13.5 OpenAM allows for stateless OAuth2 Tokens putting less strain on the tokeninfo endpoint.
You can even have a REST API retrieve a token for itself and pass that down to another REST API. The permissions you spoke of, would be scopes (arbitrary strings) and they can be assigned to an individual user. Once the token is evaluated by the REST API appropriate access controls can be applied based on these scopes.
Hope that helped.
Best
/Chris
IAM Engineer | Zalando SE | Berlin Germany


On 30 August 2016 at 19:54, Simon Moffatt <[hidden email]<mailto:[hidden email]>> wrote:

Hi Brandon

Really depends on how the REST API is being protected...

You could simply pass the iPlanet cookie into the REST API from your calling web application and let the API programmatically call OpenAM to check the cookie/tokenId validity, retrieve any attributes needed to check any necessary authZ or call the OpenAM policy engine over it's own REST endpoint to check if the user should have access to your API.

Simon

On 30/08/16 17:34, Rife, Brandon wrote:

Hello All,



I’m looking for some high level guidance on how to go about protecting REST web service calls.



The scenario is as follows. The user agent will log into a web application that is protected by OpenAM and the web application will be calling REST web services on behalf of the authenticated user.  I want the REST web service to be able to verify that that the caller is authenticated and that the caller has the necessary permissions to evoke a particular end point.  How can I leverage the fact that OpenAM is already protecting the web application that is making the calls on behalf of the user?



Thanks!



________________________________



NOTICE: This e-mail and any attachments is intended only for use by the addressee(s) named herein and may contain legally privileged, proprietary or confidential information. If you are not the intended recipient of this e-mail, you are hereby notified that any dissemination, distribution or copying of this email, and any attachments thereto, is strictly prohibited. If you receive this email in error please immediately notify me via reply email or at (800) 927-9800<tel:%28800%29%20927-9800> and permanently delete the original copy and any copy of any e-mail, and any printout.

_______________________________________________

Visit the OpenAM forum at https://forgerock.org/forum/fr-projects/openam/<https://urldefense.proofpoint.com/v2/url?u=https-3A__forgerock.org_forum_fr-2Dprojects_openam_&d=CwMFaQ&c=us5Zqth1GwlYel5cicVfQUJZpS5MPy8JOkqG08O9rxw&r=GbxPRpwQABj6xFi1cXBLB7APM3CC-JwnWvven_kvxZQ&m=9vKRwjmE_Oj-IWOqyQN6iQml1NVFWml3uibWL0oaM7Q&s=2Wxovf9MC4uLm619tGUX_94ZeLA4vd22EkGyr5Syrk8&e=>

OpenAM mailing list

[hidden email]<mailto:[hidden email]>

https://lists.forgerock.org/mailman/listinfo/openam<https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.forgerock.org_mailman_listinfo_openam&d=CwMFaQ&c=us5Zqth1GwlYel5cicVfQUJZpS5MPy8JOkqG08O9rxw&r=GbxPRpwQABj6xFi1cXBLB7APM3CC-JwnWvven_kvxZQ&m=9vKRwjmE_Oj-IWOqyQN6iQml1NVFWml3uibWL0oaM7Q&s=3uzbhF__Xe2pIugwcieFRevVVHQQ-wj2fd3gRSmcvdQ&e=>

--
[orgeRock]<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.forgerock.com_&d=CwMFaQ&c=us5Zqth1GwlYel5cicVfQUJZpS5MPy8JOkqG08O9rxw&r=GbxPRpwQABj6xFi1cXBLB7APM3CC-JwnWvven_kvxZQ&m=9vKRwjmE_Oj-IWOqyQN6iQml1NVFWml3uibWL0oaM7Q&s=0poPxpGng2rYLyw5fgNUVoxKz3wgPX-PQCTaUpyJmwk&e=>

Simon Moffatt
Advanced Customer Engineering  |  ForgeRock
tel +44 (0) 7903 347 240<tel:%2B44%20%280%29%207903%20347%20240>  |  e [hidden email]<mailto:[hidden email]>
skype simon.moffatt  |  web www.forgerock.com<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.forgerock.com_&d=CwMFaQ&c=us5Zqth1GwlYel5cicVfQUJZpS5MPy8JOkqG08O9rxw&r=GbxPRpwQABj6xFi1cXBLB7APM3CC-JwnWvven_kvxZQ&m=9vKRwjmE_Oj-IWOqyQN6iQml1NVFWml3uibWL0oaM7Q&s=0poPxpGng2rYLyw5fgNUVoxKz3wgPX-PQCTaUpyJmwk&e=>  |  twitter @simonmoffatt



[ummits]<https://urldefense.proofpoint.com/v2/url?u=https-3A__summits.forgerock.com_&d=CwMFaQ&c=us5Zqth1GwlYel5cicVfQUJZpS5MPy8JOkqG08O9rxw&r=GbxPRpwQABj6xFi1cXBLB7APM3CC-JwnWvven_kvxZQ&m=9vKRwjmE_Oj-IWOqyQN6iQml1NVFWml3uibWL0oaM7Q&s=XNXGeyddVxshSlldetrg6d0NerFR7v_uryb8gg8kLH0&e=>

_______________________________________________
Visit the OpenAM forum at https://forgerock.org/forum/fr-projects/openam/<https://urldefense.proofpoint.com/v2/url?u=https-3A__forgerock.org_forum_fr-2Dprojects_openam_&d=CwMFaQ&c=us5Zqth1GwlYel5cicVfQUJZpS5MPy8JOkqG08O9rxw&r=GbxPRpwQABj6xFi1cXBLB7APM3CC-JwnWvven_kvxZQ&m=9vKRwjmE_Oj-IWOqyQN6iQml1NVFWml3uibWL0oaM7Q&s=2Wxovf9MC4uLm619tGUX_94ZeLA4vd22EkGyr5Syrk8&e=>
OpenAM mailing list
[hidden email]<mailto:[hidden email]>
https://lists.forgerock.org/mailman/listinfo/openam<https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.forgerock.org_mailman_listinfo_openam&d=CwMFaQ&c=us5Zqth1GwlYel5cicVfQUJZpS5MPy8JOkqG08O9rxw&r=GbxPRpwQABj6xFi1cXBLB7APM3CC-JwnWvven_kvxZQ&m=9vKRwjmE_Oj-IWOqyQN6iQml1NVFWml3uibWL0oaM7Q&s=3uzbhF__Xe2pIugwcieFRevVVHQQ-wj2fd3gRSmcvdQ&e=>


_______________________________________________
Visit the OpenAM forum at https://forgerock.org/forum/fr-projects/openam/
OpenAM mailing list
[hidden email]
https://lists.forgerock.org/mailman/listinfo/openam

image001.png (15K) Download Attachment
image002.png (167K) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Guidance

Rife, Brandon
In reply to this post by Paul Figura
Thanks, Paul.  STS looks interesting.  I’ll did into it a little deeper.

From: Paul Figura <[hidden email]>
Date: Wednesday, August 31, 2016 at 9:21 AM
To: Users <[hidden email]>
Cc: Brandon Rife <[hidden email]>
Subject: Re: [OpenAM] Guidance


Hi Brandon,

there are many different ways to accomplish what you are trying to do. Someone else mentioned Oauth2 (which is a valid usecase), but in addition to that, if you want to do things directly in your application, you have a lot of options:

  *   Using Web Agents to protect certain URLS of your application based on application policies, preventing execution of certain rest calls entirely (you probably already do this).
  *   Leveraging the OpenAM session cookie to make all calls to your REST web service. Your Web service can then make a session validation for each call directly to OpenAM to validate the user session, and extract uid.
  *   Utilizing the OpenAM STS to issue tokens for each request, which can be inserted into the request for cryptographic security (though these tokens are typically SAML, and you didn't ask about that)

     *   https://forgerock.org/2016/02/openam-v-13-rest-sts-openam-token-translation/<https://urldefense.proofpoint.com/v2/url?u=https-3A__forgerock.org_2016_02_openam-2Dv-2D13-2Drest-2Dsts-2Dopenam-2Dtoken-2Dtranslation_&d=CwMDaQ&c=us5Zqth1GwlYel5cicVfQUJZpS5MPy8JOkqG08O9rxw&r=GbxPRpwQABj6xFi1cXBLB7APM3CC-JwnWvven_kvxZQ&m=-GVNDr7GV-2qOiEJuZFqSTTFCb36Tba2BUYkNZCyAJg&s=UPyUYjf7ZR1QtDtBiJC0dZ6UGYWf0z-ZZKIoiIQLgL0&e=>

  *   Creating a custom REST endpoint inside OpenAM which can do whatever logic your application would need.
  *   Leveraging OpenIG to protect your rest services

     *   https://wikis.forgerock.org/confluence/display/OPENIG/Protect+a+REST+API+with+OAuth2<https://urldefense.proofpoint.com/v2/url?u=https-3A__wikis.forgerock.org_confluence_display_OPENIG_Protect-2Ba-2BREST-2BAPI-2Bwith-2BOAuth2&d=CwMDaQ&c=us5Zqth1GwlYel5cicVfQUJZpS5MPy8JOkqG08O9rxw&r=GbxPRpwQABj6xFi1cXBLB7APM3CC-JwnWvven_kvxZQ&m=-GVNDr7GV-2qOiEJuZFqSTTFCb36Tba2BUYkNZCyAJg&s=pSusgZaqnOCfhEY-leCvXc0MVLtEDP6GIBsiX9nzqww&e=>

  *   Probably others!

We've done a lot of these integration's before, and it's really dependent on your requirements. Though you're really not limited by OpenAM, limitations usually will come from business constraints :)
Regards,
Paul Figura
Identity & Access Management Architect

[ndigo Consulting Canada]

Tel: 514-432-6233

Email: [hidden email]<mailto:[hidden email]> [cid:image002.gif@01D2038C.AEA10A60] <https://urldefense.proofpoint.com/v2/url?u=http-3A__ca.linkedin.com_in_paulfigura&d=CwMDaQ&c=us5Zqth1GwlYel5cicVfQUJZpS5MPy8JOkqG08O9rxw&r=GbxPRpwQABj6xFi1cXBLB7APM3CC-JwnWvven_kvxZQ&m=-GVNDr7GV-2qOiEJuZFqSTTFCb36Tba2BUYkNZCyAJg&s=PgWPPpafNoEQs3cK1CRKuzR-jdIwLK42ydZKrmkNYes&e=>

http://www.indigoconsulting.ca<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.indigoconsulting.ca&d=CwMDaQ&c=us5Zqth1GwlYel5cicVfQUJZpS5MPy8JOkqG08O9rxw&r=GbxPRpwQABj6xFi1cXBLB7APM3CC-JwnWvven_kvxZQ&m=-GVNDr7GV-2qOiEJuZFqSTTFCb36Tba2BUYkNZCyAJg&s=I8_SdSE0KeIe3mG_XNpAG-HxPm86wk738ftxKskmGrs&e=>






On 8/30/2016 12:34 PM, Rife, Brandon wrote:

Hello All,



I’m looking for some high level guidance on how to go about protecting REST web service calls.



The scenario is as follows. The user agent will log into a web application that is protected by OpenAM and the web application will be calling REST web services on behalf of the authenticated user.  I want the REST web service to be able to verify that that the caller is authenticated and that the caller has the necessary permissions to evoke a particular end point.  How can I leverage the fact that OpenAM is already protecting the web application that is making the calls on behalf of the user?



Thanks!



________________________________



NOTICE: This e-mail and any attachments is intended only for use by the addressee(s) named herein and may contain legally privileged, proprietary or confidential information. If you are not the intended recipient of this e-mail, you are hereby notified that any dissemination, distribution or copying of this email, and any attachments thereto, is strictly prohibited. If you receive this email in error please immediately notify me via reply email or at (800) 927-9800 and permanently delete the original copy and any copy of any e-mail, and any printout.

_______________________________________________

Visit the OpenAM forum at https://forgerock.org/forum/fr-projects/openam/<https://urldefense.proofpoint.com/v2/url?u=https-3A__forgerock.org_forum_fr-2Dprojects_openam_&d=CwMDaQ&c=us5Zqth1GwlYel5cicVfQUJZpS5MPy8JOkqG08O9rxw&r=GbxPRpwQABj6xFi1cXBLB7APM3CC-JwnWvven_kvxZQ&m=-GVNDr7GV-2qOiEJuZFqSTTFCb36Tba2BUYkNZCyAJg&s=SjiolNXdb0jpfMG_YiPyoU-JaNVeJ4mGISkmLW5aC20&e=>

OpenAM mailing list

[hidden email]<mailto:[hidden email]>

https://lists.forgerock.org/mailman/listinfo/openam<https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.forgerock.org_mailman_listinfo_openam&d=CwMDaQ&c=us5Zqth1GwlYel5cicVfQUJZpS5MPy8JOkqG08O9rxw&r=GbxPRpwQABj6xFi1cXBLB7APM3CC-JwnWvven_kvxZQ&m=-GVNDr7GV-2qOiEJuZFqSTTFCb36Tba2BUYkNZCyAJg&s=D_7OyCJnSYyb-M_M1Sn01zbpYc6PbKJgdCUu08_fm5Q&e=>


_______________________________________________
Visit the OpenAM forum at https://forgerock.org/forum/fr-projects/openam/
OpenAM mailing list
[hidden email]
https://lists.forgerock.org/mailman/listinfo/openam

image001.jpg (7K) Download Attachment
image002.gif (210 bytes) Download Attachment
Loading...