• Add a Comment
  • Edit
  • More Actions v
  • Quarantine this Entry

Comments (6)

1 Maulik Thakkar commented Permalink

it is informative but looking for more details to help me setup OAUTH demo and to use various features.

any suggestion or reference for the same?

2 David Moore commented Permalink

Hi Maulik

The only information resource I know of is the IBM Infocenter link at the end of the blog text above. I have updated this link to refer to the latest available version of this documentation.

3 Maulik Thakkar commented Permalink

Hi David,

yesterday, I came across this link
Hope other will be able to use this for their work.. :)

4 David Moore commented Permalink

Hi Maulik

I have added an additional link to a very good article on using OAuth in ISAM for Mobile. See the link at the end of the blog text above.

5 Niklas Karlsson commented Permalink


I don't know if our thinking makes any sense but we have anyway tried to combine OAuth API protection with WebSEAL junction ACL functionality. What do you think about following - is it feasible to accomplish with ISAM ?
1. client requests for OAuth2 token from token endpoint and gets one
2. client requests OAuth session endpoint and changes OAuth token to WebSEAL session cookie
3. client makes a service request through WebSEAL for a resource that is under OAuth API protection. At the same time the resource is protected with an ACL that allows the resource only with a certain group membership.

6 David Moore commented Permalink

Hi Nikklas

You've got the general idea of the Session Endpoint. However, in part 3 of your list, you probably don't need to protect the resource with Oauth (i.e. attach) since the WebSEAL session with ACL's could be used to protect the resource.
The main intent of the Session Endpoint is to enable mobile device scenarios where users don't need to supply a username and password on app startup, and traditional web session protection methods supported by WebSEAL can still be used to protect resource access. Additionally, advanced use cases that need to leverage context based authorization (CBA) features enabled by ISAM for Mobile can be supported since CBA requires WebSEAL sessions. For example, an Oauth access token or a WebSEAL session obtained via session endpoint exchange might be considered to represent a low level of identity assurance. This level might be acceptable for access to low value resources. Access to high value resources might require a higher level of identity assurance. For example, this can be enforced by an ISAM 4 Mobile policy which will trigger a one time password step up authentication. The step up would be triggered if the current WebSEAL session authentication level is below a policy defined threshold.
Hope this helps.

Add a Comment Add a Comment