A bit advanced topic for those who want to dive deep into OAM..
Check out other good blogs from Eric and Chris to understand the nitty gritty of how SSO works
A common scenario for an access manager to fulfill authn/authz services is for a client to pass the necessary credentials to an agent and the agent in turn will pass the info to OAM via the http/OAP protocols. The agents used here are ofcourse the webgates and the accessgate. The webgate being specific to the webservers and the accessgate being the customized agent for the client application that may or may not have a webserver.
Now what happens if you are in a situation if the client does not have a webserver that oracle agents normally are compatible with. The client is left alone to use the accessgate that may involve lots of customization or he may just not use access manager as his solution.
What if there's a way if you could remove the clients webserver dependency on webgate/accessgate and yet provide a standard way of communicating to Oracle Access Manager.
The solution is using OAM as a webservice and yet the necessary mechanics for a successful OAM authentication still remains unchanged. In other words the agent(accessgate) is moved to the back-end probably remaining in the same box as the OAM or another box.
So what exactly drives the OAM authentication to trigger. The following diagram depicts the above scenario.
The request for a resource can be done in two ways
From a web client such as a browser
Or from a standalone client such as a java application
Note in both the above cases the client does not require any webgates/accessgate
Before I jump into the details of the above some of the soap features worth mentioning (of which some of you may be already aware of ) are
Soap
Web services describes a standardized way of integrating Web-based applications using the XML, SOAP, WSDL and UDDI open standards over an Internet protocol backbone. XML is used to tag the data, SOAP is used to transfer the data, WSDL is used for describing the services available and UDDI is used for listing what services are available. Used primarily as a means for businesses to communicate with each other and with clients, Web services allow organisations to communicate data without intimate knowledge of each other's IT systems behind the firewall
Flow in a nut shell
Components
The components involved in the above architecture are
OAMServer: The emphasis here will be a OAM 11g server . That provides the authentication service
AccessGate: AccessGate is the building block for all webgates. Unlike webgates where it is always associated to a webserver an accessgate is used by standalone application or by a non web applications. say for eg a java program or an EJB or and C program etc. Accessgates are the only way to communicate with the OAM server
OAMAuthService: A java file that consists of the implementation APIs for the webservice. These API call the AccessGate ASDK API which communicate with the accessgate and in turn talks to the OAM server for authentication check
WebServiceClientProxy: This is a Java proxy that is used to make webservice calls on OAMAuthService All web and non web applications will instantiate this java class for OAM Auth Services
OAMAuthServlet: This is a sample servlet file that instantiates the WebServiceClientProxy and also collects the username and password and submits them to the OAM Server via the WebServiceClient Proxy
Scope
The scope is limited to sesssion token validation between similar agents. i.e the token obtained from one 10g agent can be used with another 10g agent. The 10g token cannot be used with a 11g agent. This is limited in the current release.
Sample Code
https://www.samplecode.oracle.com/tracker/tracking/linkid/prpl1004?id=S757
The sample code folder also consists of a Jdeveloper IDE project file. (Helpful for those who would like to view and deploy from an IDE)
I hope you have enjoyed this article and leave comments if any.
Check out other good blogs from Eric and Chris to understand the nitty gritty of how SSO works
A common scenario for an access manager to fulfill authn/authz services is for a client to pass the necessary credentials to an agent and the agent in turn will pass the info to OAM via the http/OAP protocols. The agents used here are ofcourse the webgates and the accessgate. The webgate being specific to the webservers and the accessgate being the customized agent for the client application that may or may not have a webserver.
Now what happens if you are in a situation if the client does not have a webserver that oracle agents normally are compatible with. The client is left alone to use the accessgate that may involve lots of customization or he may just not use access manager as his solution.
What if there's a way if you could remove the clients webserver dependency on webgate/accessgate and yet provide a standard way of communicating to Oracle Access Manager.
The solution is using OAM as a webservice and yet the necessary mechanics for a successful OAM authentication still remains unchanged. In other words the agent(accessgate) is moved to the back-end probably remaining in the same box as the OAM or another box.
So what exactly drives the OAM authentication to trigger. The following diagram depicts the above scenario.
The request for a resource can be done in two ways
From a web client such as a browser
Or from a standalone client such as a java application
Note in both the above cases the client does not require any webgates/accessgate
Before I jump into the details of the above some of the soap features worth mentioning (of which some of you may be already aware of ) are
Soap
- Uses standard internet HTTP
- Uses XML to send and receive messages
- Platform independent
- Language independent
- A protocol for exchanging information in a decentralized and distributed environment
- Soap happens to be one of the key features of Microsoft's .Net Architecture especially, Web Services
Web services describes a standardized way of integrating Web-based applications using the XML, SOAP, WSDL and UDDI open standards over an Internet protocol backbone. XML is used to tag the data, SOAP is used to transfer the data, WSDL is used for describing the services available and UDDI is used for listing what services are available. Used primarily as a means for businesses to communicate with each other and with clients, Web services allow organisations to communicate data without intimate knowledge of each other's IT systems behind the firewall
Flow in a nut shell
- The client requests for a resource.
- The request is submitted to a proxy client which in turn makes a soap call to OAMAuthService which is a webservice.
- This service calls the OAM 10g ASDK API.
- The ASDK API invokes the accessgate (which is installed) to communicate to the OAM server .
- The OAM server performs authentication and passes an encrypted token back to the client.
Components
The components involved in the above architecture are
OAMServer: The emphasis here will be a OAM 11g server . That provides the authentication service
AccessGate: AccessGate is the building block for all webgates. Unlike webgates where it is always associated to a webserver an accessgate is used by standalone application or by a non web applications. say for eg a java program or an EJB or and C program etc. Accessgates are the only way to communicate with the OAM server
OAMAuthService: A java file that consists of the implementation APIs for the webservice. These API call the AccessGate ASDK API which communicate with the accessgate and in turn talks to the OAM server for authentication check
WebServiceClientProxy: This is a Java proxy that is used to make webservice calls on OAMAuthService All web and non web applications will instantiate this java class for OAM Auth Services
OAMAuthServlet: This is a sample servlet file that instantiates the WebServiceClientProxy and also collects the username and password and submits them to the OAM Server via the WebServiceClient Proxy
Scope
The scope is limited to sesssion token validation between similar agents. i.e the token obtained from one 10g agent can be used with another 10g agent. The 10g token cannot be used with a 11g agent. This is limited in the current release.
Sample Code
https://www.samplecode.oracle.com/tracker/tracking/linkid/prpl1004?id=S757
The sample code folder also consists of a Jdeveloper IDE project file. (Helpful for those who would like to view and deploy from an IDE)
I hope you have enjoyed this article and leave comments if any.
4 comments:
I found the post interesting but at the end I was a bit disappointed that you are still not using a complete OAM 11g solution. The other question I have is have you taken in to consideration how you are going to provide a logout solution? Using the 11g webgate plugin with OHS as a reverse proxy was a bit of a challenge understanding how to create a logout to destroy and inactivate the user session. If you don't take that in to consideration you need to make sure that your user doesn't create too many sessions and exceed the number defined in OAM.
Hi Derick,
So using this web service 11g feature to support my non-browser clients which can only pass base64 authorization headers to the webgate to do the authentication? These clients cannot handle the cookies and would be passing this Az header with every request.
We've done customization in 10g to support this by writing a web server plug-in but would like to leverage the out-of-the-box feature without taking this custom piece along with 11g upgrade.
Looking forward for your comments.
Don,
I believe you are referring to when the user closes the browser without clicking on logout link..
In OAM11g we have a max session timeout property and default is something like 8 sessions..You can configure this to a smaller value.
Ranjan..
We will be supporting OAM 10g Plugin feature in the upcoming releases..
I really cannot say right now it will be a OOTB feature as requirements varies from one customer to another..
Post a Comment