Wednesday Jan 29, 2014

Under the covers - Using Mobile OAuth for Native app authentication and Server side Single Sign On

Introduction 

As we roll out OAM's Mobile OAuth functionality and address our customer's use cases around securing native mobile apps accessing OAuth enabled services and APIs, this blog post outlines a real world mobile enterprise extranet use case and unravels the syntax and HTTP requests/responses for OAM's OAuth REST interfaces that are to be used by Mobile OAuth clients with whatever be their mobile platform of choice - iOS or Android.

Use Case

Avitek Retail is a large multi brand retail enterprise. In addition to several other products, Avitek Retail also sells shoes and accessories from different competing brands in their retail outlets. Avitek Retail’s warehouse managers must ensure that adequate inventory levels are maintained to meet customer demand and they typically need access to supplier catalogs to replenish inventory.

Avitek Retail- an Oracle Access Manager customer has built its own inventory replenishment application that is used by its warehouse managers. Avitek Retail originally built its inventory replenishment application as a web based application but has also recently made it available as a mobile native application for both the iOS and Android platforms that can be downloaded from iTunes or the Google Play app stores. In our scenario, ABC Designer Shoe Inc provides a catalog of designer shoes as a REST service that requires a valid OAuth 2.0 access token. This catalog needs to be accessed by Avitek Retail’s Inventory Replenishment application. From an OAuth perspective then we have the following scenario: 

  • OAuth 2.0 Server: Oracle Access Manager 11gR2PS2 deployed at Avitek Retail
  • OAuth 2.0 Client: Avitek Retail’s Inventory Replenishment application
  • OAuth Resource Server: ABC Designer Shoe Catalog
  • Resource Owner: Tom Dole- Warehouse Manager at Avitek Retail who owns the shoe catalog provided by ABC Designer Shoe Inc to Avitek Retail.

Mobile OAuth Flow

Following is the entire mobile flow:

  1. Tom Dole (ABC Shoe Inc Catalog Resource Owner and Avitek Retail Warehouse Manager) attempts to access the Inventory Replenishment application (Mobile OAuth Client)
  2. The Inventory Replenishment application (Mobile OAuth client) requests a pre-authorization code with a device token from the OAM OAuth 2.0 Server.
  3. The OAM OAuth 2.0 Server returns pre-authorization code over APNS(iOS).
  4. The Inventory Replenishment application (Mobile OAuth Client) sends a registration request with device claims and pre-authorization code to the OAM OAuth 2.0 Server. The OAM OAuth 2.0 server uses user-agent redirection, authenticates the user, checks for device security, gets user consent for Mobile OAuth Client registration ( - if Tom Dole is accessing the app for the first time on the mobile device) and returns a client token over APNS/GCM to the Mobile OAuth Client.
  5. The traditional OAuth flow starts now. The OAuth server checks for device security and depending on the configuration, presents the user with a consent page for accessing the ABC Shoe Designer Inc Catalog
  6. The OAM OAuth 2.0 authorization server sends an authorization code to the Inventory Replenishment application (Mobile OAuth client)
  7. The Inventory Replenishment application (Mobile OAuth client) requests for an access token from the OAuth authorization server by sending the authorization code, client token and device claims.
  8. The OAM OAuth 2.0 server returns access token with optional refresh token to the Inventory Replenishment application (Mobile OAuth Client)
  9. The Inventory Replenishment application (Mobile OAuth Client) presents the Access Token to the ABC Shoe Designer Inc Catalog (OAuth 2.0 Resource Server)
  10. The ABC Shoe Designer Inc Catalog (OAuth 2.0 Resource Server) validates the token with the OAM OAuth 2.0 Authorization Server
  11. The ABC Shoe Designer Inc Catalog (OAuth 2.0 Resource Server) provides the requested content to the Inventory Replenishment application (Mobile OAuth Client)

Solution - Under the covers

And here's the secret sauce-- a working sample of the HTTP requests/responses and the syntax of the Mobile OAuth REST interfaces used to enable the Mobile OAuth client application:

Step 1 Create Pre Authorization Code for Client Token
curl -i -H 'Content-Type: application/x-www-form-urlencoded;charset=UTF-8' -H 'Cache-Control: no-cache, no-store, must-revalidate' --request POST http://slc01mkk.us.oracle.com:14100/ms_oauth/oauth2/endpoints/oauthservice/tokens -d 'grant_type=client_credentials&client_id=1097ae507ea649da81a660293e75d8e2&oracle_device_profile=eyJvcmFjbGU6aWRtOmNsYWltczpjbGllbnQ6c2RrdmVyc2lvbiI6IjExLjEuMi4wLjAiLCJvcmFjbGU6aWRtOmNsYWltczpjbGllbnQ6Z2VvbG9jYXRpb24iOiJMb2NhdGlvbiB1cGRhdGUgZmFpbGVkLExvY2F0aW9uIHVwZGF0ZSBmYWlsZWQiLCJvcmFjbGU6aWRtOmNsYWltczpjbGllbnQ6bmV0d29ya3R5cGUiOiJXSUZJIiwib3JhY2xlOmlkbTpjbGFpbXM6Y2xpZW50Om9zdHlwZSI6ImlQaG9uZSBPUyIsIm9yYWNsZTppZG06Y2xhaW1zOmNsaWVudDpwaG9uZWNhcnJpZXJuYW1lIjoiVU5LTk9XTiIsIm9yYWNsZTppZG06Y2xhaW1zOmNsaWVudDpsb2NhbGUiOiJlbi1VUyIsIm9yYWNsZTppZG06Y2xhaW1zOmNsaWVudDpvc3ZlcnNpb24iOiI2LjEiLCJvcmFjbGU6aWRtOmNsYWltczpjbGllbnQ6amFpbGJyb2tlbiI6ZmFsc2UsIm9yYWNsZTppZG06Y2xhaW1zOmNsaWVudDp2cG5lbmFibGVkIjpmYWxzZSwiaGFyZHdhcmVJZHMiOnsib3JhY2xlOmlkbTpjbGFpbXM6Y2xpZW50OnVkaWQiOiJFQjY5QzZCOC0yNTJBLTQyOTQtQkYyMy1CQUIwNTU2RkNCMjAiLCJvcmFjbGU6aWRtOmNsYWltczpjbGllbnQ6cGhvbmVudW1iZXIiOiJVTktOT1dOIiwib3JhY2xlOmlkbTpjbGFpbXM6Y2xpZW50Om1hY2FkZHJlc3MiOiIwMDoxRjo1QjpGNzpDRDo4OSIsIm9yYWNsZTppZG06Y2xhaW1zOmNsaWVudDppbWVpIjoiVU5LTk9XTiJ9fQ==&oracle_requested_assertions=oracle-idm%3A%2Foauth%2Fassertion-type%2Fclient-identity%2Fmobile-client-pre-authz-code-client'


Status: 200
{"expires_in":300,"token_type":"Bearer","oracle_tk_context":"pre_azc","access_token":"eyJhbGciOiJSUzUxMiIsInR5cCI6IkpXVCIsImtpZCI6Im9yYWtleSJ9.eyJvcmFjbGUub2F1dGgudGtfY29udGV4dCI6InByZV9hemMiLCJvcmFjbGUub2F1dGgucHJlX2F6Yy50dGMiOiJjbGllbnRfYXNzZXJ0aW9uIiwiZXhwIjoxMzg4OTc5NDc2MDAwLCJpc3MiOiJ3d3cub3JhY2xlLmV4YW1wbGUuY29tIiwicHJuIjpudWxsLCJqdGkiOiI1OTJiNTZhOS1iZmYyLTQxY2YtYWMzMi05NzA3ZWViODAzNmQiLCJvcmFjbGUub2F1dGguY2xpZW50X29yaWdpbl9pZCI6IjEwOTdhZTUwN2VhNjQ5ZGE4MWE2NjAyOTNlNzVkOGUyIiwib3JhY2xlLm9hdXRoLnN2Y19wX24iOiJPQXV0aFNlcnZpY2VQcm9maWxlIiwiaWF0IjoxMzg4OTc5MTc2MDAwLCJvcmFjbGUub2F1dGguaWRfZF9pZCI6IjEyMzQ1Njc4LTEyMzQtMTIzNC0xMjM0LTEyMzQ1Njc4OTAxMiIsInVzZXIudGVuYW50Lm5hbWUiOiJEZWZhdWx0RG9tYWluIn0.bp_P6Ub8IVSZ_ABsvHSYmXirTkMd7BkcDBKdvLT1rRZJjmTnt7jXjVGME-QcpEc5crA5FYN0ISSiMvZlC0neQSZ0lYuIS3OdXrBSa5XipBloFsBQt7XJiNcYfywWbJSK_cg9seSZGKsHA5fM72icsm-Oz_SVaa8T0bB6GA3YYnU"}


Step 2 Create Authz code for Client Token
http://slc01mkk.us.oracle.com:14100/ms_oauth/oauth2/endpoints/oauthservice/authorize?client_id=1097ae507ea649da81a660293e75d8e2&response_type=code&redirect_uri=http%3A%2F%2Fslc01mkk.us.oracle.com%3A7001%2Fidmoauthtool%2F&scope=none&oracle_requested_assertions=urn%3Aietf%3Aparams%3Aoauth%3Aclient-assertion-type%3Ajwt-bearer&oracle_pre_authz_code=eyJhbGciOiJSUzUxMiIsInR5cCI6IkpXVCIsImtpZCI6Im9yYWtleSJ9.eyJvcmFjbGUub2F1dGgudGtfY29udGV4dCI6InByZV9hemMiLCJvcmFjbGUub2F1dGgucHJlX2F6Yy50dGMiOiJjbGllbnRfYXNzZXJ0aW9uIiwiZXhwIjoxMzg4OTc5NDc2MDAwLCJpc3MiOiJ3d3cub3JhY2xlLmV4YW1wbGUuY29tIiwicHJuIjpudWxsLCJqdGkiOiI1OTJiNTZhOS1iZmYyLTQxY2YtYWMzMi05NzA3ZWViODAzNmQiLCJvcmFjbGUub2F1dGguY2xpZW50X29yaWdpbl9pZCI6IjEwOTdhZTUwN2VhNjQ5ZGE4MWE2NjAyOTNlNzVkOGUyIiwib3JhY2xlLm9hdXRoLnN2Y19wX24iOiJPQXV0aFNlcnZpY2VQcm9maWxlIiwiaWF0IjoxMzg4OTc5MTc2MDAwLCJvcmFjbGUub2F1dGguaWRfZF9pZCI6IjEyMzQ1Njc4LTEyMzQtMTIzNC0xMjM0LTEyMzQ1Njc4OTAxMiIsInVzZXIudGVuYW50Lm5hbWUiOiJEZWZhdWx0RG9tYWluIn0.bp_P6Ub8IVSZ_ABsvHSYmXirTkMd7BkcDBKdvLT1rRZJjmTnt7jXjVGME-QcpEc5crA5FYN0ISSiMvZlC0neQSZ0lYuIS3OdXrBSa5XipBloFsBQt7XJiNcYfywWbJSK_cg9seSZGKsHA5fM72icsm-Oz_SVaa8T0bB6GA3YYnU


Step 3 Create Client Token
curl -i -H 'Content-Type: application/x-www-form-urlencoded;charset=UTF-8' -H 'Cache-Control: no-cache, no-store, must-revalidate' --request POST http://slc01mkk.us.oracle.com:14100/ms_oauth/oauth2/endpoints/oauthservice/tokens -d 'grant_type=authorization_code&code=eyJhbGciOiJSUzUxMiIsInR5cCI6IkpXVCIsImtpZCI6Im9yYWtleSJ9.eyJvcmFjbGUub2F1dGgucmVkaXJlY3QtdXJpIjoiaHR0cDovL3NsYzAxbWtrLnVzLm9yYWNsZS5jb206NzAwMS9pZG1vYXV0aHRvb2wvIiwib3JhY2xlLm9hdXRoLmN0LnJlZ191c2VyX2lkX3R5cGUiOiJMREFQX1VJRCIsImlzcyI6Ind3dy5vcmFjbGUuZXhhbXBsZS5jb20iLCJvcmFjbGU6aWRtOmNsYWltczpjbGllbnQ6aW1laSI6IlVOS05PV04iLCJvcmFjbGUub2F1dGguc3ZjX3BfbiI6Ik9BdXRoU2VydmljZVByb2ZpbGUiLCJpYXQiOjEzODg5NzkxNzkwMDAsIm9yYWNsZS5vYXV0aC5hemMudHRjIjoiY2xpZW50X2Fzc2VydGlvbiIsIm9yYWNsZS5vYXV0aC50a19jb250ZXh0IjoiYXpjIiwiZXhwIjoxMzg4OTgwMDc5MDAwLCJvcmFjbGUub2F1dGguY3QucmVnX3VzZXIiOiJ3ZWJsb2dpYyIsIm9yYWNsZTppZG06Y2xhaW1zOmNsaWVudDptYWNhZGRyZXNzIjoiMDA6MUY6NUI6Rjc6Q0Q6ODkiLCJwcm4iOm51bGwsImp0aSI6IjYyNmY2MWVhLTdjODktNGM1MC05NzdmLTVhNThiNmUxNTMzYiIsIm9yYWNsZS5vYXV0aC5jbGllbnRfb3JpZ2luX2lkIjoiMTA5N2FlNTA3ZWE2NDlkYTgxYTY2MDI5M2U3NWQ4ZTIiLCJvcmFjbGUub2F1dGguaWRfZF9pZCI6IjEyMzQ1Njc4LTEyMzQtMTIzNC0xMjM0LTEyMzQ1Njc4OTAxMiIsInVzZXIudGVuYW50Lm5hbWUiOiJEZWZhdWx0RG9tYWluIn0.Wm8Xx_lWvq80yLwfThx4rOxwLsDanws0Dzbr3yUdncJe4VBvg0Oz-zGAtNk5i0kjeknyyrt5J3BC7of9NOYYR5dwgwpXMB8uf6qnfdnsxfvX8PFAgsX_rJ68rViFRksghg9Z0juiFPGBE3upBYjawKQXm6bx5UCce6h-N0856wM&client_id=1097ae507ea649da81a660293e75d8e2&redirect_uri=http%3A%2F%2Fslc01mkk.us.oracle.com%3A7001%2Fidmoauthtool%2F&oracle_device_profile=eyJvcmFjbGU6aWRtOmNsYWltczpjbGllbnQ6c2RrdmVyc2lvbiI6IjExLjEuMi4wLjAiLCJvcmFjbGU6aWRtOmNsYWltczpjbGllbnQ6Z2VvbG9jYXRpb24iOiJMb2NhdGlvbiB1cGRhdGUgZmFpbGVkLExvY2F0aW9uIHVwZGF0ZSBmYWlsZWQiLCJvcmFjbGU6aWRtOmNsYWltczpjbGllbnQ6bmV0d29ya3R5cGUiOiJXSUZJIiwib3JhY2xlOmlkbTpjbGFpbXM6Y2xpZW50Om9zdHlwZSI6ImlQaG9uZSBPUyIsIm9yYWNsZTppZG06Y2xhaW1zOmNsaWVudDpwaG9uZWNhcnJpZXJuYW1lIjoiVU5LTk9XTiIsIm9yYWNsZTppZG06Y2xhaW1zOmNsaWVudDpsb2NhbGUiOiJlbi1VUyIsIm9yYWNsZTppZG06Y2xhaW1zOmNsaWVudDpvc3ZlcnNpb24iOiI2LjEiLCJvcmFjbGU6aWRtOmNsYWltczpjbGllbnQ6amFpbGJyb2tlbiI6ZmFsc2UsIm9yYWNsZTppZG06Y2xhaW1zOmNsaWVudDp2cG5lbmFibGVkIjpmYWxzZSwiaGFyZHdhcmVJZHMiOnsib3JhY2xlOmlkbTpjbGFpbXM6Y2xpZW50OnVkaWQiOiJFQjY5QzZCOC0yNTJBLTQyOTQtQkYyMy1CQUIwNTU2RkNCMjAiLCJvcmFjbGU6aWRtOmNsYWltczpjbGllbnQ6cGhvbmVudW1iZXIiOiJVTktOT1dOIiwib3JhY2xlOmlkbTpjbGFpbXM6Y2xpZW50Om1hY2FkZHJlc3MiOiIwMDoxRjo1QjpGNzpDRDo4OSIsIm9yYWNsZTppZG06Y2xhaW1zOmNsaWVudDppbWVpIjoiVU5LTk9XTiJ9fQ=='


Status: 200
{"oracle_client_assertion_type":"urn:ietf:params:oauth:client-assertion-type:jwt-bearer","expires_in":604800,"token_type":"Bearer","oracle_tk_context":"client_assertion","refresh_token":"eyJhbGciOiJSUzUxMiIsInR5cCI6IkpXVCIsImtpZCI6Im9yYWtleSJ9.eyJvcmFjbGUub2F1dGguY3QucmVnX3VzZXJfaWRfdHlwZSI6IkxEQVBfVUlEIiwiaXNzIjoid3d3Lm9yYWNsZS5leGFtcGxlLmNvbSIsIm9yYWNsZTppZG06Y2xhaW1zOmNsaWVudDppbWVpIjoiVU5LTk9XTiIsIm9yYWNsZS5vYXV0aC5ydC50dGMiOiJjbGllbnRfYXNzZXJ0aW9uIiwib3JhY2xlLm9hdXRoLnN2Y19wX24iOiJPQXV0aFNlcnZpY2VQcm9maWxlIiwiaWF0IjoxMzg4OTc5MTkxMDAwLCJvcmFjbGUub2F1dGgudGtfY29udGV4dCI6InJlZnJlc2hfdG9rZW4iLCJleHAiOjEzOTEzOTgzOTEwMDAsIm9yYWNsZS5vYXV0aC5jdC5yZWdfdXNlciI6IndlYmxvZ2ljIiwib3JhY2xlOmlkbTpjbGFpbXM6Y2xpZW50Om1hY2FkZHJlc3MiOiIwMDoxRjo1QjpGNzpDRDo4OSIsInBybiI6bnVsbCwianRpIjoiMWUwNTU5N2QtMDRkNy00YjhlLWI4ZTYtYWM5OGFjYzE0OWVlIiwib3JhY2xlLm9hdXRoLmNsaWVudF9vcmlnaW5faWQiOiIxMDk3YWU1MDdlYTY0OWRhODFhNjYwMjkzZTc1ZDhlMiIsInVzZXIudGVuYW50Lm5hbWUiOiJEZWZhdWx0RG9tYWluIiwib3JhY2xlLm9hdXRoLmlkX2RfaWQiOiIxMjM0NTY3OC0xMjM0LTEyMzQtMTIzNC0xMjM0NTY3ODkwMTIifQ.JvPQIDUffCrC9fv7SpDQmIYMWQJZRjVCxdT_pndOYB4_ET3NpJyiRezGscb8dtLnrmUwISyD0LEwnqPIWd7hAkpXxacvxSaM3OEijDnHRzejVEaZGSPXTlTVuxLKxHb9w_f80E4TIkdSh8nXmW9808wmg9tC7RqDw-pURqmuBvg","access_token":"eyJhbGciOiJSUzUxMiIsInR5cCI6IkpXVCIsImtpZCI6Im9yYWtleSJ9.eyJvcmFjbGUub2F1dGguY3QucmVnX3VzZXJfaWRfdHlwZSI6IkxEQVBfVUlEIiwic3ViIjoiMTA5N2FlNTA3ZWE2NDlkYTgxYTY2MDI5M2U3NWQ4ZTIiLCJpc3MiOiJ3d3cub3JhY2xlLmV4YW1wbGUuY29tIiwib3JhY2xlOmlkbTpjbGFpbXM6Y2xpZW50OmltZWkiOiJVTktOT1dOIiwib3JhY2xlLm9hdXRoLnN2Y19wX24iOiJPQXV0aFNlcnZpY2VQcm9maWxlIiwiaWF0IjoxMzg4OTc5MTkxMDAwLCJvcmFjbGUub2F1dGgucHJuLmlkX3R5cGUiOiJDbGllbnRJRCIsImV4cCI6MTM4OTU4Mzk5MTAwMCwib3JhY2xlLm9hdXRoLmN0LnJlZ191c2VyIjoid2VibG9naWMiLCJvcmFjbGUub2F1dGgudGtfY29udGV4dCI6ImNsaWVudF9hc3NlcnRpb24iLCJvcmFjbGU6aWRtOmNsYWltczpjbGllbnQ6bWFjYWRkcmVzcyI6IjAwOjFGOjVCOkY3OkNEOjg5IiwicHJuIjoiMTA5N2FlNTA3ZWE2NDlkYTgxYTY2MDI5M2U3NWQ4ZTIiLCJqdGkiOiIxYWIyZTg1ZC1lYWM5LTRhMzItODU4MC0xODE5ODhjNDFlZTUiLCJ1c2VyLnRlbmFudC5uYW1lIjoiRGVmYXVsdERvbWFpbiIsIm9yYWNsZS5vYXV0aC5pZF9kX2lkIjoiMTIzNDU2NzgtMTIzNC0xMjM0LTEyMzQtMTIzNDU2Nzg5MDEyIn0.aW-Vkkb3YTN6xWOwMHQn0W1drhorC9vW9hTK512_VW0JwYlGd924p9qd4cR1qhJqv802j7NsUPhmra9mYgrKaFrT-aIvPOGHpWcOqu3-tvwkGY7DM_twmRh-jQn_CqHvLpgflbpDYO8KAsp3xyVF6qupM8l2wc4IuQ7hZUMHI5c"}


Step 4 Create Pre Authorization Code for Access Token
curl -i -H 'Content-Type: application/x-www-form-urlencoded;charset=UTF-8' -H 'Cache-Control: no-cache, no-store, must-revalidate' --request POST http://slc01mkk.us.oracle.com:14100/ms_oauth/oauth2/endpoints/oauthservice/tokens -d 'grant_type=client_credentials&client_id=1097ae507ea649da81a660293e75d8e2&oracle_requested_assertions=oracle-idm%3A%2Foauth%2Fassertion-type%2Fclient-identity%2Fmobile-client-pre-authz-code-access&oracle_device_profile=eyJvcmFjbGU6aWRtOmNsYWltczpjbGllbnQ6c2RrdmVyc2lvbiI6IjExLjEuMi4wLjAiLCJvcmFjbGU6aWRtOmNsYWltczpjbGllbnQ6Z2VvbG9jYXRpb24iOiJMb2NhdGlvbiB1cGRhdGUgZmFpbGVkLExvY2F0aW9uIHVwZGF0ZSBmYWlsZWQiLCJvcmFjbGU6aWRtOmNsYWltczpjbGllbnQ6bmV0d29ya3R5cGUiOiJXSUZJIiwib3JhY2xlOmlkbTpjbGFpbXM6Y2xpZW50Om9zdHlwZSI6ImlQaG9uZSBPUyIsIm9yYWNsZTppZG06Y2xhaW1zOmNsaWVudDpwaG9uZWNhcnJpZXJuYW1lIjoiVU5LTk9XTiIsIm9yYWNsZTppZG06Y2xhaW1zOmNsaWVudDpsb2NhbGUiOiJlbi1VUyIsIm9yYWNsZTppZG06Y2xhaW1zOmNsaWVudDpvc3ZlcnNpb24iOiI2LjEiLCJvcmFjbGU6aWRtOmNsYWltczpjbGllbnQ6amFpbGJyb2tlbiI6ZmFsc2UsIm9yYWNsZTppZG06Y2xhaW1zOmNsaWVudDp2cG5lbmFibGVkIjpmYWxzZSwiaGFyZHdhcmVJZHMiOnsib3JhY2xlOmlkbTpjbGFpbXM6Y2xpZW50OnVkaWQiOiJFQjY5QzZCOC0yNTJBLTQyOTQtQkYyMy1CQUIwNTU2RkNCMjAiLCJvcmFjbGU6aWRtOmNsYWltczpjbGllbnQ6cGhvbmVudW1iZXIiOiJVTktOT1dOIiwib3JhY2xlOmlkbTpjbGFpbXM6Y2xpZW50Om1hY2FkZHJlc3MiOiIwMDoxRjo1QjpGNzpDRDo4OSIsIm9yYWNsZTppZG06Y2xhaW1zOmNsaWVudDppbWVpIjoiVU5LTk9XTiJ9fQ=='


Status: 200
{"expires_in":300,"token_type":"Bearer","oracle_tk_context":"pre_azc","access_token":"eyJhbGciOiJSUzUxMiIsInR5cCI6IkpXVCIsImtpZCI6Im9yYWtleSJ9.eyJvcmFjbGUub2F1dGgudGtfY29udGV4dCI6InByZV9hemMiLCJleHAiOjEzODg5Nzk0OTIwMDAsImlzcyI6Ind3dy5vcmFjbGUuZXhhbXBsZS5jb20iLCJwcm4iOm51bGwsImp0aSI6ImY0OWQzNmE0LTE4MmItNGE2Yy1iMDY0LWU5Zjc5ZGFlMmFkOCIsIm9yYWNsZS5vYXV0aC5jbGllbnRfb3JpZ2luX2lkIjoiMTA5N2FlNTA3ZWE2NDlkYTgxYTY2MDI5M2U3NWQ4ZTIiLCJvcmFjbGUub2F1dGguc3ZjX3BfbiI6Ik9BdXRoU2VydmljZVByb2ZpbGUiLCJpYXQiOjEzODg5NzkxOTIwMDAsIm9yYWNsZS5vYXV0aC5pZF9kX2lkIjoiMTIzNDU2NzgtMTIzNC0xMjM0LTEyMzQtMTIzNDU2Nzg5MDEyIiwidXNlci50ZW5hbnQubmFtZSI6IkRlZmF1bHREb21haW4ifQ.DK5SoC6vndw16EV7o0P1nItngCDH-clwES1fsm6Z7AQTo3eaMbae6q3IChABrN1KsWqUXyzFostpGidsbefvX0zz-ochjP72z9hpnhqkO2ZoQLWC3qK3yQ6tQeSMxJavTJi-HKzJLQ84omTv4-FN9n9kR8anLYvgFG7rB6-XOeo"}


Step 5 Call
http://slc01mkk.us.oracle.com:14100/ms_oauth/oauth2/endpoints/oauthservice/authorize?client_id=1097ae507ea649da81a660293e75d8e2&response_type=code&redirect_uri=http%3A%2F%2Fslc01mkk.us.oracle.com%3A7001%2Fidmoauthtool%2F&scope=UserProfile.users+UserProfile.groups+UserProfile.me+UserProfile.secretkey.management&oracle_pre_authz_code=eyJhbGciOiJSUzUxMiIsInR5cCI6IkpXVCIsImtpZCI6Im9yYWtleSJ9.eyJvcmFjbGUub2F1dGgudGtfY29udGV4dCI6InByZV9hemMiLCJleHAiOjEzODg5Nzk0OTIwMDAsImlzcyI6Ind3dy5vcmFjbGUuZXhhbXBsZS5jb20iLCJwcm4iOm51bGwsImp0aSI6ImY0OWQzNmE0LTE4MmItNGE2Yy1iMDY0LWU5Zjc5ZGFlMmFkOCIsIm9yYWNsZS5vYXV0aC5jbGllbnRfb3JpZ2luX2lkIjoiMTA5N2FlNTA3ZWE2NDlkYTgxYTY2MDI5M2U3NWQ4ZTIiLCJvcmFjbGUub2F1dGguc3ZjX3BfbiI6Ik9BdXRoU2VydmljZVByb2ZpbGUiLCJpYXQiOjEzODg5NzkxOTIwMDAsIm9yYWNsZS5vYXV0aC5pZF9kX2lkIjoiMTIzNDU2NzgtMTIzNC0xMjM0LTEyMzQtMTIzNDU2Nzg5MDEyIiwidXNlci50ZW5hbnQubmFtZSI6IkRlZmF1bHREb21haW4ifQ.DK5SoC6vndw16EV7o0P1nItngCDH-clwES1fsm6Z7AQTo3eaMbae6q3IChABrN1KsWqUXyzFostpGidsbefvX0zz-ochjP72z9hpnhqkO2ZoQLWC3qK3yQ6tQeSMxJavTJi-HKzJLQ84omTv4-FN9n9kR8anLYvgFG7rB6-XOeo


Request an Access Token
curl -i -H 'Accept: */*' --request POST http://slc01mkk.us.oracle.com:14100/ms_oauth/oauth2/endpoints/oauthservice/tokens -d 'grant_type=authorization_code&client_id=1097ae507ea649da81a660293e75d8e2&code=eyJhbGciOiJSUzUxMiIsInR5cCI6IkpXVCIsImtpZCI6Im9yYWtleSJ9.eyJvcmFjbGUub2F1dGgucmVkaXJlY3QtdXJpIjoiaHR0cDovL3NsYzAxbWtrLnVzLm9yYWNsZS5jb206NzAwMS9pZG1vYXV0aHRvb2wvIiwib3JhY2xlLm9hdXRoLnVzZXJfb3JpZ2luX2lkX3R5cGUiOiJMREFQX1VJRCIsIm9yYWNsZS5vYXV0aC51c2VyX29yaWdpbl9pZCI6IndlYmxvZ2ljIiwiaXNzIjoid3d3Lm9yYWNsZS5leGFtcGxlLmNvbSIsIm9yYWNsZTppZG06Y2xhaW1zOmNsaWVudDppbWVpIjoiVU5LTk9XTiIsIm9yYWNsZS5vYXV0aC5zdmNfcF9uIjoiT0F1dGhTZXJ2aWNlUHJvZmlsZSIsImlhdCI6MTM4ODk3OTE5NzAwMCwib3JhY2xlLm9hdXRoLnRrX2NvbnRleHQiOiJhemMiLCJleHAiOjEzODg5ODAwOTcwMDAsIm9yYWNsZTppZG06Y2xhaW1zOmNsaWVudDptYWNhZGRyZXNzIjoiMDA6MUY6NUI6Rjc6Q0Q6ODkiLCJwcm4iOm51bGwsImp0aSI6Ijk2MjVjYWZkLWVkYmUtNDJjNC05ZGMzLWEyMmMyOWMxZTlmZCIsIm9yYWNsZS5vYXV0aC5zY29wZSI6IlVzZXJQcm9maWxlLnNlY3JldGtleS5tYW5hZ2VtZW50IFVzZXJQcm9maWxlLnVzZXJzIFVzZXJQcm9maWxlLm1lIFVzZXJQcm9maWxlLmdyb3VwcyIsIm9yYWNsZS5vYXV0aC5jbGllbnRfb3JpZ2luX2lkIjoiMTA5N2FlNTA3ZWE2NDlkYTgxYTY2MDI5M2U3NWQ4ZTIiLCJ1c2VyLnRlbmFudC5uYW1lIjoiRGVmYXVsdERvbWFpbiIsIm9yYWNsZS5vYXV0aC5pZF9kX2lkIjoiMTIzNDU2NzgtMTIzNC0xMjM0LTEyMzQtMTIzNDU2Nzg5MDEyIn0.knflM_0d1NvEZD2Vs5N-piHj-tq3KMNoXLiJkqNTwd73lwAxnwkiy02RLOvyOt3FM05chszQGWl2ahEog7g8tNgTmRG5sDrmLm9HWkpuwqWTStYXf-Sz-thOV3IRU5BN311T-neHb81sq5f6kslqTGvjBnfXXeBzlUDld5DVYVI&oracle_device_profile=eyJvcmFjbGU6aWRtOmNsYWltczpjbGllbnQ6c2RrdmVyc2lvbiI6IjExLjEuMi4wLjAiLCJvcmFjbGU6aWRtOmNsYWltczpjbGllbnQ6Z2VvbG9jYXRpb24iOiJMb2NhdGlvbiB1cGRhdGUgZmFpbGVkLExvY2F0aW9uIHVwZGF0ZSBmYWlsZWQiLCJvcmFjbGU6aWRtOmNsYWltczpjbGllbnQ6bmV0d29ya3R5cGUiOiJXSUZJIiwib3JhY2xlOmlkbTpjbGFpbXM6Y2xpZW50Om9zdHlwZSI6ImlQaG9uZSBPUyIsIm9yYWNsZTppZG06Y2xhaW1zOmNsaWVudDpwaG9uZWNhcnJpZXJuYW1lIjoiVU5LTk9XTiIsIm9yYWNsZTppZG06Y2xhaW1zOmNsaWVudDpsb2NhbGUiOiJlbi1VUyIsIm9yYWNsZTppZG06Y2xhaW1zOmNsaWVudDpvc3ZlcnNpb24iOiI2LjEiLCJvcmFjbGU6aWRtOmNsYWltczpjbGllbnQ6amFpbGJyb2tlbiI6ZmFsc2UsIm9yYWNsZTppZG06Y2xhaW1zOmNsaWVudDp2cG5lbmFibGVkIjpmYWxzZSwiaGFyZHdhcmVJZHMiOnsib3JhY2xlOmlkbTpjbGFpbXM6Y2xpZW50OnVkaWQiOiJFQjY5QzZCOC0yNTJBLTQyOTQtQkYyMy1CQUIwNTU2RkNCMjAiLCJvcmFjbGU6aWRtOmNsYWltczpjbGllbnQ6cGhvbmVudW1iZXIiOiJVTktOT1dOIiwib3JhY2xlOmlkbTpjbGFpbXM6Y2xpZW50Om1hY2FkZHJlc3MiOiIwMDoxRjo1QjpGNzpDRDo4OSIsIm9yYWNsZTppZG06Y2xhaW1zOmNsaWVudDppbWVpIjoiVU5LTk9XTiJ9fQ==&client_assertion=eyJhbGciOiJSUzUxMiIsInR5cCI6IkpXVCIsImtpZCI6Im9yYWtleSJ9.eyJvcmFjbGUub2F1dGguY3QucmVnX3VzZXJfaWRfdHlwZSI6IkxEQVBfVUlEIiwic3ViIjoiMTA5N2FlNTA3ZWE2NDlkYTgxYTY2MDI5M2U3NWQ4ZTIiLCJpc3MiOiJ3d3cub3JhY2xlLmV4YW1wbGUuY29tIiwib3JhY2xlOmlkbTpjbGFpbXM6Y2xpZW50OmltZWkiOiJVTktOT1dOIiwib3JhY2xlLm9hdXRoLnN2Y19wX24iOiJPQXV0aFNlcnZpY2VQcm9maWxlIiwiaWF0IjoxMzg4OTc5MTkxMDAwLCJvcmFjbGUub2F1dGgucHJuLmlkX3R5cGUiOiJDbGllbnRJRCIsImV4cCI6MTM4OTU4Mzk5MTAwMCwib3JhY2xlLm9hdXRoLmN0LnJlZ191c2VyIjoid2VibG9naWMiLCJvcmFjbGUub2F1dGgudGtfY29udGV4dCI6ImNsaWVudF9hc3NlcnRpb24iLCJvcmFjbGU6aWRtOmNsYWltczpjbGllbnQ6bWFjYWRkcmVzcyI6IjAwOjFGOjVCOkY3OkNEOjg5IiwicHJuIjoiMTA5N2FlNTA3ZWE2NDlkYTgxYTY2MDI5M2U3NWQ4ZTIiLCJqdGkiOiIxYWIyZTg1ZC1lYWM5LTRhMzItODU4MC0xODE5ODhjNDFlZTUiLCJ1c2VyLnRlbmFudC5uYW1lIjoiRGVmYXVsdERvbWFpbiIsIm9yYWNsZS5vYXV0aC5pZF9kX2lkIjoiMTIzNDU2NzgtMTIzNC0xMjM0LTEyMzQtMTIzNDU2Nzg5MDEyIn0.aW-Vkkb3YTN6xWOwMHQn0W1drhorC9vW9hTK512_VW0JwYlGd924p9qd4cR1qhJqv802j7NsUPhmra9mYgrKaFrT-aIvPOGHpWcOqu3-tvwkGY7DM_twmRh-jQn_CqHvLpgflbpDYO8KAsp3xyVF6qupM8l2wc4IuQ7hZUMHI5c&client_assertion_type=urn%3Aietf%3Aparams%3Aoauth%3Aclient-assertion-type%3Ajwt-bearer&redirect_uri=http%3A%2F%2Fslc01mkk.us.oracle.com%3A7001%2Fidmoauthtool%2F'


Status: 200
{"expires_in":3600,"token_type":"Bearer","access_token":"eyJhbGciOiJSUzUxMiIsInR5cCI6IkpXVCIsImtpZCI6Im9yYWtleSJ9.eyJzdWIiOiJ3ZWJsb2dpYyIsIm9yYWNsZS5vYXV0aC51c2VyX29yaWdpbl9pZF90eXBlIjoiTERBUF9VSUQiLCJvcmFjbGUub2F1dGgudXNlcl9vcmlnaW5faWQiOiJ3ZWJsb2dpYyIsImlzcyI6Ind3dy5vcmFjbGUuZXhhbXBsZS5jb20iLCJvcmFjbGU6aWRtOmNsYWltczpjbGllbnQ6aW1laSI6IlVOS05PV04iLCJvcmFjbGUub2F1dGguc3ZjX3BfbiI6Ik9BdXRoU2VydmljZVByb2ZpbGUiLCJpYXQiOjEzODg5NzkyMDEwMDAsIm9yYWNsZS5vYXV0aC5wcm4uaWRfdHlwZSI6IkxEQVBfVUlEIiwib3JhY2xlLm9hdXRoLnRrX2NvbnRleHQiOiJyZXNvdXJjZV9hY2Nlc3NfdGsiLCJleHAiOjEzODg5ODI4MDEwMDAsIm9yYWNsZTppZG06Y2xhaW1zOmNsaWVudDptYWNhZGRyZXNzIjoiMDA6MUY6NUI6Rjc6Q0Q6ODkiLCJwcm4iOiJ3ZWJsb2dpYyIsImp0aSI6ImQ4ODlkNDVhLTVlNTMtNDllMi1hZDJmLWEwNTI1ZTNlZjY0NiIsIm9yYWNsZS5vYXV0aC5zY29wZSI6IlVzZXJQcm9maWxlLnNlY3JldGtleS5tYW5hZ2VtZW50IFVzZXJQcm9maWxlLnVzZXJzIFVzZXJQcm9maWxlLm1lIFVzZXJQcm9maWxlLmdyb3VwcyIsIm9yYWNsZS5vYXV0aC5jbGllbnRfb3JpZ2luX2lkIjoiMTA5N2FlNTA3ZWE2NDlkYTgxYTY2MDI5M2U3NWQ4ZTIiLCJ1c2VyLnRlbmFudC5uYW1lIjoiRGVmYXVsdERvbWFpbiIsIm9yYWNsZS5vYXV0aC5pZF9kX2lkIjoiMTIzNDU2NzgtMTIzNC0xMjM0LTEyMzQtMTIzNDU2Nzg5MDEyIn0.P8YpUfbyTS4jLmVjbtSBG0FJ1BjxRec3iavNDGtG87coqg5QhTaXOJFyuJrVcL68k54acmxN-4gBvAFyQLFwN8fMlGa29iX-vGMO8_o9zq-ggwRlPPxROvvrzkJp_ODW3xdbQuuxhx0X4WBsiUVpCPxCdShqPbJ3sqHf6eeoQSY"}

Wednesday Jan 22, 2014

Using Oracle STS to connect to Amazon Web Services

Introduction 

While we do see fewer opportunities for Oracle STS than say traditional browser based identity federation or more recently OAuth for enterprises to securely connect to cloud hosted applications or services, Oracle STS still offers a compelling differentiation for several customers. In this post, I'll share a key use case for one of our marquee customers that is an ideal fit for Oracle STS.

Overview

The customer's application needs to securely access resources hosted by Amazon Web Service as outlined here in the graphic below from http://docs.aws.amazon.com/STS/latest/UsingSTS/CreatingSAML.html

Essentially with AWS, the client application that needs to access AWS hosted resources for a user needs to first securely get user information from the enterprise identity store in the form of a SAML assertion. Users don't have direct access to AWS.  Also, the application then needs to exchange that SAML assertion with AWS for temporary security credentials with the appropriate authorization for the user so that it can access user specific resources from AWS.

How can we accomplish it with OSTS

- A  App executed by the client sends a WS-Trust request to the OSTS with

o username/password in SOAP headers

o AppliesTo set to https://signin.aws.amazon.com/saml

- O  OSTS would be configured to

o Validate credentials against LDAP user store

o Have a Relying Party partner representing the AWS STS, with a mapping URL set to https://signin.aws.amazon.com/saml

- O  OSTS validates the creds, creates Assertion based on user LDAP record (specified in the OSTS SAML Issuance template)

o NameID format is set to persistent

o NameID value is set to an LDAP User ID (it cannot be random string, as this is not supported in STS use cases, only in Federation SSO)

o SAML Attributes include https://aws.amazon.com/SAML/Attributes/Role and https://aws.amazon.com/SAML/Attributes/RoleSessionName

- T   AWS STS would need to be configured to trust OSTS based on:

o The OSTS issuerID/providerID (specified in the OSTS SAML Issuance template)

o The OSTS signing key (see http://docs.oracle.com/cd/E27559_01/admin.1112/e27239/osts_key.htm#BGBCDGBC, section 33.3.3.1)


Monday Jan 20, 2014

The case for Mobile OAuth in the OAM OAuth service

Introduction 

Several OAuth Clients are consumer applications that cannot keep the client secret confidential (application password or private key). These OAuth Clients are called public clients or non-confidential clients. Mobile Client applications i.e. native applications on mobile devices are also categorized as public clients because when a native application is first downloaded from an app store to a device, the client credentials that uniquely identify the client application are baked into the application. Since all users that download the native application have access to the binary, a malicious user could easily decompile the client credentials out of the binary and insert their own credentials. During an OAuth flow when the access code gets exchanged for the access token this leads to a major vulnerability as there is now no secure means of really identifying who is actually receiving and using the access token.

Hence, providing a mechanism to secure the mobile application on the device in order to ensure trusted access is a key requirement specifically for enterprise mobile applications that routinely require access to sensitive data. The OAM OAuth Service provides key features in the OAM OAuth 2.0 Service’s Mobile OAuth flow to facilitate secure enterprise mobile access for OAuth Client applications.

How it's done : Overview - Mobile Application Registration and Mobile Device Identification

The OAM OAuth  Service provides built-in support for a mechanism for mobile applications to be first registered with OAM to use OAuth Access Services. Security is enforced for mobile applications by creating a client profile and issuing client tokens specific to the application on a device. The user provides explicit authorization to register each mobile OAuth application. In the OAM OAuth 2.0 Service, mobile application registration is modeled using the same paradigm as the OAuth protocol flow where mobile application registration is modeled as a scope for which the user needs to provide explicit consent. As a result of the mobile application registration the application is issued a client token. The mobile application always submits this client token as an input parameter for accessing OAM OAuth 2.0 Service end points. Furthermore, the OAM OAuth 2.0 service also allows easy coupling of device identification with mobile application registration where mobile devices and applications can be checked against fraud and security using a built-in integration with Oracle Adaptive Access Manager (OAAM). The mobile application passes device claims along with the client token for accessing OAM OAuth 2.0 Service end points and the OAM OAuth2.0 Service provides a configuration to make certain claims as mandatory and certain claims as optional.

Sunday Jan 19, 2014

Using the OAM Mobile SDK to secure native mobile apps - Android SDK

Introduction

In this blog post I'll round out addressing a key strategic area for our customers--i.e. securing mobile native apps with Oracle Access Manager using the mobile client SDK. In previous posts I covered securing iOS based mobile clients using the iOS SDK as well as covered the required OAM server side configurations involved in securing these applications. In this post I'll cover the Android SDK. Finally, the sample android app used here in this post as an Eclipse ADT project is available for download at :
https://www.dropbox.com/sh/6tc7vxyn9zn43an/JloXNybqN_

Invoking Authentication Services

Initialize

The first step is to create an object of OMMobileSecurityService and initialize the Android SDK by providing required Mobile and Social server details.

This constructor initializes the OMMobileSecurityService object using the Map<String, Object>:

public OMMobileSecurityService(Context context, Map<String, Object> configProperties,OMMobileServiceCallback callback)

This enables you to specify required and optional parameters to initialize the SDK using the OM_PROP_* properties in the Map. The OM_PROP_OAMMS_URL parameter is the URL (including protocol, host name, and port number) required to reach the Mobile and Social server. Only the HTTP and HTTPS protocols are supported. The OM_PROP_APPNAME parameter is a unique identifier that identifies the application. This String value must match the application "Name" value located in the Application Profile section of the Mobile and Social server administration console. The OM_PROP_OAMMS_SERVICE_DOMAIN parameter specifies the name of the service domain that has been created on the Mobile and Social server. The application profile that the OM_PROP_APPNAME refers to should be defined as an application profile in this service domain.

The following snippet in ConfigurationActivity#OnClick() populates the Map<String,Object>:

Map<String, Object> oamConfigProp = new HashMap<String, Object>();

oamConfigProp.put(

OMMobileSecurityService.OM_PROP_AUTHSERVER_TYPE,

OMMobileSecurityService.AuthServerType.OAMMS);

oamConfigProp.put(

OMMobileSecurityService.OM_PROP_OAMMS_SERVICE_DOMAIN,

oamDomain);

oamConfigProp.put(OMMobileSecurityService.OM_PROP_APPNAME,

oamAppId);

oamConfigProp.put(OMMobileSecurityService.OM_PROP_OAMMS_URL,

oamServerURL + ":" + oamPort);

The following snippets in LoginActivity#getMobileSecurityService() and LoginApplication#getMobileSecurityService() create a OMMobileSecurityService object:

if (mss == null)

{

try
{

mss = ((LoginApplication) getApplication())

  .getMobileSecurityService(getApplicationContext(),

new OMMobileServiceCallbackImpl());

  }  ...

}

public OMMobileSecurityService getMobileSecurityService(Context c,

OMMobileServiceCallback callback) throws OMMobileSecurityException {

if (!isMssInitialized) {

if (mOAMConfigMap != null) {

mss = new OMMobileSecurityService(c, mOAMConfigMap, callback);

isMssInitialized = true;

}

}

return mss;

}

The context argument is the context of the Application object. Pass the context that is returned by Context#getApplicationContext(). The callback argument specifies an instance of a class that has implemented the interface OMMobileServiceCallback. The SDK uses this to return control to the application after calling OMMobileSecurityService#setup() and OMMobileSecurityService#authenticate().

 Register

You need to register the current activity with the SDK before invoking certain methods in the OMMobileSecurityService, such as setup(), authenticate(), processSSORequest(), and processHttpRequest() and deregister the activity when it is not in the foreground. This is done to ensure that there are no memory leaks. To give the reference to the current activity, register the current activity in onResume() and deregister the activity in onPause() for activities that call the methods mentioned previously. If you call any of these methods in onCreate() of the activity, register the activity before calling these methods. To deregister the activity, when the activity moves to the background, use the OMMobileSecurityService#deregisterActivity() method.

LoginActivity#getMobileSecurityService() and LoginActivity#OnResume() registers the current activity in our sample application:

private OMMobileSecurityService getMobileSecurityService()

{

if (mss == null)

{

try

...

{

if (mss != null)

{

mss.registerActivity(this);

  }

protected void onResume()

{

super.onResume();

if (mss != null)

{

mss.registerActivity(this);

}

  …

}

Setup

The setup method gets the configured security policies and the application profile from the Mobile and Social server. This method also gets a list of the service endpoints (the URLs) that are required for connecting to the authentication, authorization, and user profile services on the Mobile and Social server. This is an asynchronous call. When the application profile download completes, or if a problem like network unavailability is encountered, the SDK returns control to the calling activity by calling callback.processSetupResponse(OMApplicationProfile profile, OMMobileSecurityException mse). If the application profile could not be downloaded, the exception details can be found in OMMobileSecurityException mse. The SDK downloads and stores the application profile. The SDK will not download the application profile on subsequent calls to OMMobileSecurityService#setup() until the ProfileCacheDuration setting has expired. The ProfileCacheDuration setting is defined in the application profile.

The following snippets in LoginActivity#OnClickView() and LoginActivity#initSetUp() invoke setup() on the OMMobileSecurityService object:

public void onClick(View v)

{

switch (v.getId())

{

try

{

if (!((LoginApplication) getApplication())

.isSetupCompleted())

{

initSetUP();

}


}

private void initSetUP()

{

mss = null;

if (getMobileSecurityService() != null)

getMobileSecurityService().setup();

}

}

The following snippet in LoginActivity#OMMobileServiceCallbackImpl#processSetupResponse() implements the logic when the SDK returns control back to the application after performing setup:

public void processSetupResponse(OMApplicationProfile profile, OMMobileSecurityException mse)

{

if (profile != null)

{

((LoginApplication) getApplication()).setSetupCompleted(true);

Toast.makeText(LoginActivity.this, "Setup Done",

Toast.LENGTH_SHORT).show();

login.setTextColor(Color.WHITE);

}

else

{

Toast.makeText(LoginActivity.this, "Setup failed",

Toast.LENGTH_SHORT).show();

((LoginApplication) getApplication()).setSettingsFailedOAM();

displayConfigureSettings();

mss = null;

}

}

Authenticate

Once the setup successfully completes, the business application can perform authentication by either calling OMMobileSecurityService#authenticate() or OMMobileSecurityService#processSSORequest(). Use the processSSORequest()instead of authenticate() if your app also needs to act as an SSO agent—the OMMobileSecurityService#processSSORequest() supports both self authentication as well as the ability to allow the app to act as an SSO agent.

Both these calls are asynchronous calls and the SDK will return control to the application once authentication is completed or if authentication has failed for some reason. The control will be returned to the application through OMMobileServiceCallback#processAuthenticationResponse(OMAuthenticationContext context, OMMobileSecurityException mse). All the details with respect to the authenticated session are available in the OMAuthenticationContext context. If authentication fails for some reason, the details are available in OMMobileSecurityException mse. If an application (SSO client) needs to authenticate using the SSO Agent App, the main activity has to call OMMobileSecurityService#processSSORequest(intent)

The authenticate() and the processSSORequest() methods return a ViewFlipper object that holds the processing view. When the view is focused it will trigger the actual authentication flow. If a valid authentication context is already available in the cache for the above request, then it will return control back to the calling business application without performing any request to the server.

The following snippet in LoginActivity#OnClickView() demonstrates authentication:

authView= getMobileSecurityService().authenticate();

LinearLayout.LayoutParams params = new LinearLayout.LayoutParams(LinearLayout.LayoutParams.MATCH_PARENT, LinearLayout.LayoutParams.MATCH_PARENT); relLayout.addView(authView, 1, params);

The following snippet in LoginActivity#OMMobileServiceCallbackImpl#processAuthenticationResponse implements the logic when the SDK returns control back to the application after performing authentication:

public void processAuthenticationResponse(OMAuthenticationContext context, OMMobileSecurityException mse)

{

Log.d(TAG, "Process authentication response() context = " + context);

String msg;

if (context == null)

{

isAuthenticated = false;

}

else

{

isAuthenticated = true;

}

relLayout.removeView(authView);

if (authView != null)

authView.invalidate();

if (isAuthenticated)

{

Intent i = new Intent();

i.setAction(LoginConstants.ACTION_LOGIN_SUCCESS);

i.putExtra(LoginConstants.USER_AUTHENTICATED, true);

startActivityForResult(i, LoginConstants.AUTH_SUCCESS);

}

..

}

Offline Authentication

Mobile and Social from R2PS1 onwards supports offline authentication. This feature requires that first the “Offline Authentication” setting is enabled in the Application Profile in the OAM Admin Console. Next, while initializing the SDK to create the OMMobileSecurityService object, add the OM_PROP_CONNECTIVITY_MODE key as a parameter to the Map<String,Object> as shown earlier in the Initialize section . You can specify the way that offline authentication should happen by providing one of the following values to this key:

OMConnectivityMode.ONLINE - Always authenticate with the server. Fails if device cannot reach the Internet.

OMConnectivityMode.OFFLINE - Authenticates locally with cached credentials. Offline authentication happens even if the device is online and can reach the server.

OMConnectivityMode.AUTO - Authentication happens with the server if the server is reachable and happens offline if the device is not connected to the Internet.

Invoking Relying Party Authentication

From an SDK perspective, Relying Party Authentication is identical to invoking Authentication Services as outlined above. Additionally, there are two areas to be considered:

1. To authenticate using a Relying Party, the data scheme in the main activity of the application should match the URL scheme configured in the Application profile. The main activity is the activity that has the <data android:scheme="xyz" /> in its <intent-filter> in the Android Manifest and xyz should be the same as the URL scheme configured in the Application profile. Finally, the main activity name is the name that should be used as the Android Package name in the Application Profile configuration.

2. If your apps will authenticate against different OAM servers, or with the same OAM server but different authentication schemes, then one OMMobileSecurityService instance should be created for every server or authentication scheme. So, for example, in this case since the same Login app authenticates against OAM server and against Facebook for different use cases, we need to create separate instances of OMMobileSecurityService to handle each use case.

Invoking REST Services

The Mobile SDK makes it easy to securely access REST services that are protected by OAM. The Android Client SDK automatically injects an access token when invoking an OAM R2 Webgate protected REST resource. It maintains a cache of access tokens that it has obtained during the mobile application's lifetime. It then either fetches an access token for the webgate from its cache or if an access token for the Webgate is not available in the Mobile and Social SDK cache, it sends a REST request to the Mobile and Social server to obtain the Access Token for the Webgate--provided the resource is protected by an Access Management 11g R2 Webgate. If a valid user token is not found for the current application (for example, if the user is not authenticated), the SDK throws an exception.

The following snippet in AccountStatement#RetrieveSummary demonstrates invoking a REST service:

class RetriveSummary extends AsyncTask<String, Integer, ArrayList<String>>

{

@Override

protected ArrayList<String> doInBackground(String... params)

{

// super.

ArrayList<String> resultList = new ArrayList<String>();

if (mss != null)

{

Log.d("AccountStatement", "rest service = " + restService);

// create a Http Request with the webservice

HttpRequest httpreq = new HttpGet(restService);

// in order to access the protected web service add the user-agent which is configured in the webgate settings.

httpreq.setHeader("User-Agent", "OIC-Agent");

try

{

// invoke sdk processHttpRequest() on the mss instance.

HttpResponse response = mss.processHttpRequest(httpreq);

final JSONArray array;

try

{

array = new JSONArray(parseHttpResponse(response));

for (int i = 0; i < array.length(); i++)

{

resultList.add(array.getString(i));

}

}

catch (IOException e)

{

e.printStackTrace();

}

}

catch (OMMobileSecurityException e)

{

e.printStackTrace();

}

catch (JSONException e)

{

e.printStackTrace();

}

return resultList;

}

return resultList;

}

As can be seen above, the Mobile and Social Android Client SDK provides a simple OMMobileSecurityService#processHttpRequest(HttpRequest httpRequest) method to access REST Web services or any Web resource protected by Access Manager. However, the "user-agent" http header value must be set to the OAMAuthUserAgentPrefix value that is defined in the webgate configuration to activate non browser client functionality.

About

Kanishk Mahajan is a Principal Product Manager in Oracle Identity Management with product responsibility within the Oracle Access Management suite

Search

Categories
Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today