Support for sub realm, module and authentication chain for REST authentication

We’re working on support REST authentication for sub realm, module, and authentication chain.

Support sub realm, add uri=realm%3D<sub realm name> e.g.
http://www.example.com:8080/opensso/identity/authenticate? username=demo&password=changeit&uri=realm%3D/sub
Support authentication module, add uri=module%3D<module name> e.g. http://www.example.com:8080/opensso/identity/authenticate? username=demo&password=changeit&uri=module%3DDataStore
Support authentication chain add uri=service%3D<authentication chain name> e.g. http://www.example.com:8080/opensso/identity/authenticate? username=demo&password=changeit&uri=service%3DldapService

Hence you can login to a sub realm with a authentication module like this
http://www.example.com:8080/opensso/identity/authenticate? username=demo&password=changeit& uri=realm%3D/sub%26module%3DDataStore

This support shall be made available to you soon.

Author: dennisseah

Dennis works for Microsoft Corporation and is based in the Bay Area of California. He has over 25 years of professional software development working experience. He shares his views and opinions on interesting matters that he has encountered. All his writings are solely his own opinions and views; and do not reflect the perspectives of any companies and/or organizations. View all posts by dennisseah

19 thoughts on “Support for sub realm, module and authentication chain for REST authentication”

Dmitry says:

November 14, 2008 at 9:19 pm

Great! Looking forward to that fix. How soon it will come into stable version?

Reply
Dmitry says:

November 15, 2008 at 1:42 pm

And what about service part? I,e, something like service://iPlanetAMWebAgentService/ prefix. Auth level definetely makes sense also (may be service://iPlanetAMWebAgentService:1:1/). And concerning realm parameter here. In the example it is “/sub”. Is this a full name which may be “/sub/subsub” or an alias (should be “sub”)?

Reply
Dmitry says:

November 15, 2008 at 2:15 pm

looked at the attached patch. Here is the code:

if (uri != null) {
StringTokenizer st = new StringTokenizer(uri, “&”);
while (st.hasMoreTokens()) {
String s = st.nextToken();
int idx = s.indexOf(“=”);
if ((idx != -1) && (idx != (s.length() -1))) {
String k = s.substring(0, idx);
String v = s.substring(idx+1);
if (k.equals(“realm”) && (realm == null)) {
realm = v;
} else if (k.equals(“module”) &&
(authIndexType == null)) {
authIndexType = AuthContext.IndexType.MODULE_INSTANCE;
authIndexValue = v;
} else if (k.equals(“service”) &&
(authIndexType == null)) {
authIndexType = AuthContext.IndexType.SERVICE;
authIndexValue = v;
}
}
}
}
if (realm == null) {
realm = “/”;
}

This means using realm alias (“sub”). Here is a service name parsed like realm. And maybe that makes no sense of uri parameter at all. Because 3 additional parameters (realm, module, service) could be added to “authenticate” method instead of uri.

Reply
dennisseah says:

November 17, 2008 at 5:54 pm

I do not know about the service part. Essentially, we are supporting realm, authentication module and chain.

Regarding the realm, out of the box, we have root realm which is /. The example that I have given is a sub-realm under the root realm.

Please send your question to users@opensso.java.net so we can better iron out things and get features that you need.

thanks

Reply
Radboud says:

February 6, 2009 at 1:50 pm

We’re using OpenSSO 8.0 Enterprise with a sub realm utilizing an ‘indira-ized’ OpenDS data store.
We use C# SOAP calls to get to the identity services.
it appears that using URI to enter ‘realm=myRealm’ already works fine, e.g.
SSOToken = wsSSO.authenticate(Username, Password, “realm=openDS”);
What however does NOT seem to work is calling either the .read or .search web methods.
Procedure:
1. make sure amadmin account exists in ou=people in OpenDS.
2. use ACI to allow read/search permissions for amadmin.
3. authenticate amadmin in the proper realm, e.g. AdminToken = wsSSO(“openDSAdmin”,”password”,”realm=OpenDS”)
4. using the adminToken, read user properties for a user in the OpenDS data store:
UserDetails=wsSSO(“openDSUser”,null, AdminToken)
executing this last statement results in com.sun.identity.idsvcs.GeneralFailure.
I would expect that the service ‘knows’ about the realm and therefore data store of the Admin, but this appears not to be the case.
To validate that my admin is able to search for a given user in OpenDS, I used ldapsearch to double-check, and that worked as expected.

Am I overlooking something?

Thanks

Reply
Radboud says:

February 6, 2009 at 1:57 pm

Hi…forget about previous e-mail, I made some typo’s which I only discovered after posting it…Here’s the mail again:

We’re using OpenSSO 8.0 Enterprise with a sub realm utilizing an ‘indira-ized’ OpenDS user data store.
We use C# SOAP calls to get to the identity services.
it appears that using the URI attribute to enter ‘realm=OpenDS’ already works fine, e.g.
SSOToken = wsSSO.authenticate(Username, Password, “realm=openDS”);
What however does NOT seem to work is calling either the .read or .search web methods.
Procedure:
1. make sure openDSAdmin account exists in ou=people in OpenDS.
2. create ACI to allow read/search permissions for openDSAdmin.
3. authenticate openDSAdmin in the proper realm, e.g. AdminToken = wsSSO.authenticate(“openDSAdmin”,”password”,”realm=OpenDS”)
4. using the adminToken, read user properties for a user in the OpenDS data store:
UserDetails=wsSSO.read(“openDSUser”,null, AdminToken)
executing this last statement results in com.sun.identity.idsvcs.GeneralFailure.
I would expect that the service ‘knows’ about the realm and therefore data store of the Admin, but this appears not to be the case.
To validate that my admin is able to search for a given user in OpenDS, I used ldapsearch to double-check, and that worked as expected.

Am I overlooking something?

Thanks

Reply
dennisseah says:

February 6, 2009 at 10:26 pm

Hi
can you send your questions on to users@opensso.dev.java.net?
and pls subscribe to this alias so that you can get your answer when people responds to it. My co-workers are experts in this field and I am not 😦

To Subscribe
1. create an account under http://java.net
2. login using the account
3. visit https://opensso.dev.java.net/servlets/ProjectMailingListList to subscribe

thanks

Reply
Chris says:

April 17, 2009 at 8:10 pm

Is module based REST authentication now supported ? Authenticating by “http://www.example.com:8080/opensso/identity/authenticate?
username=demo&password=changeit&uri=module%3DDataStore” seems to use the default authentication chain – at least with build 6.

Reply
Ravikant Kadbe says:

July 13, 2009 at 2:34 pm

Hi Indira,

we are using Opensso with Liferay, and we have created a plug-in which authenticate all the liferay users from the Opensso login screen. We need to to access the custom data store using REST call.
URL we are using is as following:
http://localhost:8080/opensso/UI/Login?realm=test_realm&username=test@liferay.com&password=test.
Can you guide us, how can we access this with REST call in our code.

Help will be appreciated, as this is on very high priority.

Thanks in advance.
Regards,
Ravikant Kadbe

Reply
1. dennisseah says:
  
  July 13, 2009 at 10:01 pm
  
  hi Ravikant
  
  the Rest URL should be
  http://localhost:8080/opensso/identity/authenticate?
  username=test@liferay.com&password=test&uri=realm%3D/test_realm
  
  Reply
  1. Ravikant Kadbe says:
    
    July 14, 2009 at 6:45 am
    
    Hi Dennisseah,
    
    Thanks for your prompt reply, I have tried this url and i m getting error as,
    
    HTTP Status 401 – exception.name=com.sun.identity.idsvcs.InvalidCredentials Authentication Failed!!
    
    let me know ur suggestion on this.
    
    Thanks,
    Ravikant Kadbe
Ravikant Kadbe says:

July 13, 2009 at 2:43 pm

Hi Dennis,

I m sorry i was reading a blog of Indira and put her name..in my posting.

Ravikant Kadbe

Reply
dennisseah says:

July 15, 2009 at 6:16 am

are you sure that test@liferay.com exist?
or if it does, the password is test

Reply
jiang says:

July 29, 2009 at 1:51 pm

Hi Dennisseah,

When I tried to login with a user in the root realm, it works, but when I tried to login a user into a sub realm, it fails.

curl -d “username=testuser1&password=test&uri=realm%3Dtestrealm” http://localhost:8080/opensso/identity/authenticate

gives a 410 Unauthorized.
I also tried to add module%3DDataStore
that doesn’t work either. In indira’s blog, it says to just use
realm=testrealm, I tried that, and it doesn’t work either.

Any advice is appreciated.

Jiang

Reply
1. dennisseah says:
  
  July 29, 2009 at 2:18 pm
  
  which release of OpenSSO are you using?
  sub realm support is recently added to OpenSSO Express 7.
  
  and are you certain that the user is in the sub realm?
  
  please send your questions to users@opensso.dev.java.net, we can take it from here.
  
  thanks
  
  Reply
Maxim J. says:

January 12, 2010 at 1:08 pm

Nice. I’ll use that at my web-page

Reply
Sreeram says:

January 16, 2010 at 2:43 am

We have a issue in OPENSSO ENTERPRISE EDITION 8.0 .

We have written a plugin for authenticating user. We have tested our plugin code with express version of Opensso 8.0 and everything worked fine including the REST url to authenticate users.

I have rebuilt the opensso war with the plugin code (no changes) and ENTERPRISE version of OpenSSO. We are able to deploy it successfully. We are able to login via login page with a valid user (Sales1/Password1). When we try authenticating the same user using REST url (given below) Iam getting authentication failed error. When I look at the debug.out file I dont see that the plugin is being accessed, when we try authenticating using REST url. I see that the plugin is being accessed when we login via the login page. The same REST url is working with Express version.

Is there any difference in ENTERPRISE version OPENSSO 8.0 and EXPRESS version of OPENSSO 8.0?

REST URL:

http://ServerName>:8080/opensso/identity/authenticate?username=Sales1&password=Password1&uri=realm%3DESS%26module%3DESSDataStore

Any help is appreciated.

Reply
1. dennisseah says:
  
  January 16, 2010 at 8:30 am
  
  Hi Sreeram
  
  I believe that you are using OpenSSO Express 7.
  
  OpenSSO Enterprise Edition 8.0 does not support authentication module in REST authentication interface. But OpenSSO Express 7 does.
  
  We added the support after we shipped OpenSSO Enterprise Edition 8.0.
  
  thanks
  
  Reply
  1. Sreeram says:
    
    January 16, 2010 at 3:01 pm
    
    Hi,
    
    Thanks for the reply. I looked at the documentation for OPENSSO Enterprise edition 8.0 and it gives details of how to use REST interface (url given below). This made me thing it is supported in enterprise edition.
    
    Any idea which version of enterprise edition supports the REST interface?
    
    Is EXPRESS version supported by SUN?
    
    Are there any issues in using EXPRESS edition in production environment.
    
    http://docs.sun.com/app/docs/doc/820-3748/gjdsc?a=view
    
    Thanks
    Sreeram