Integrating with external SSO (no application login screen)

[deadlockgr]

Dear all,

I use Seam 2.2.1.CR1 on Weblogic 10.3.2 (11g). I want to use an external SSO (the proprietary one Oracle provides, based on OID). I would like to integrate this external login (the login screen belongs to the SSO). Please note that I don't want to use an LdapStore. If I got this right, this would require me to have a login page through my application, which would then somehow connect to the LDAP and login. I want to use the external login screen provided by the SSO.

SOME THOUGHTS

I don't see the procedure of using this SSO to login to be any different than using any Authenticator of WebLogic. Both with the SSO and with the BASIC authentication on the Default Authenticator, the application-wise result is the same: the user enters the application and on each HttpServletRequest the method getRemoteUser() returns the username with which the user logged in (either on the SSO or the BASIS login), and the .isUserInRole('blah') returns true/false depending on the roles assigned through the authentication. So, I see the two authentications to be exactly the same, programming-wise.

THE QUESTION

My question concerns how this can be integrated with the Seam Security. Seam in Action explains how a custom login screen can be included in the application, which populates the Identity component and the Credentials components. Seam then uses these components to apply the high-level security restrictions, like s:hasRole.

However, in my application I DON'T want a login screen. All I want is to be able to somehow use the Seam Security with what I already have: The roles and username in the HttpServletRequest.

I have found this thread (See at the end), but I am not sure I quite understand. A question, for instance, is if extending the Identity is what I need.

Another question is that in Seam in Action Dan Allen says that having a login page is mandatory, which I don't want to have. From page 449:

Only Seam isn’t going to know where to direct a nonauthenticated user when this
page is requested because you haven’t specified a login page. If a login page hasn’t
been set, Seam throws a NotLoggedInException.

Generally, I think that integrating an external SSO (or any Application Server authenticator) with Seam is still poorly documented, although it is a very common business requirement. I guess we'll all hang in until the guys finish with Seam 3.

Meanwhile, any general / specific directions?

Cheers!

-- http://seamframework.org/Community/HelpWithIdentityloginAndAcceptExternallyAuthenticatedPrincipal

[deadlockgr]

Ping!

[kapitanpetko]

deadlock gr wrote on Jul 05, 2010 04:17:


Ping!

Pong! This is all very specific, and proprietary, so what do you expect? Have a look at Identity.acceptExternallyAuthenticatedPrincipal().

Even if/when Seam 3 is done, don't expect new documentation for Seam 2. The good news is it's open source, so you can take it apart, fix it and then blog/brag about it :)

[deadlockgr]

Hi Nikolay, thanks for the response.

You are right, all this is proprietary, but let's forget about it for a moment.

I have an externally authenticated Principal. Although the users are stored externally, I still need to store in the DB some user-specific data (i.e. user preferences).

Do I need for this a JPA or LDAP store?

Do I have to have a login screen? (The external authentication has its own login screen, where the user is already redirected).

Do I need to override Identity.login, or define an authentication method? Or both?

Thanks again,

Markos

[kapitanpetko]

deadlock gr wrote on Jul 05, 2010 04:59:


I have an externally authenticated Principal. Although the users are stored externally, I still need to store in the DB some user-specific data (i.e. user preferences).

User preferences has nothing to do with authentication, so just create a table for that and use the username to look stuff up.

Do I need for this a JPA or LDAP store?

No.

Do I have to have a login screen? (The external authentication has its own login screen, where the user is already redirected).

No.

Do I need to override Identity.login, or define an authentication method? Or both?

Shouldn't need to. I haven't done this with Seam, so this might be wrong/incomplete, but generally:

1. you set the login page in pages.xml to whatever you use to login (external SSO system)


2. you get redirected, you type your credentials


3. the SSO system returns some kind of token with your username/roles


4. you pass this token to your Seam app, extract the username/roles and tell Seam security to use those (Identity.acceptExternallyAuthenticatedPrincipal()), instead of providing a login page and authenticator.

How exactly you do this depends on the particular SSO system. But since it is external, you can't expect HttpServletRequest.getRemoteUser() to be automatically populated, you will have to do some work to get you userid there. Look at the Seam security OpenID code for inspiration.

HTH

[deadlockgr]

Thanks man. This clears things out a lot.

[kyatim]

I have used SSO System (CAS Server).

I have no idea about your SSO system but i think it will be the same process.
You should setup a Filter (to be executed first for each request) that verify if user is authenticated (if no the user should be redirected to the SSO Server login page)
The SSO server generate a autentication tocken (ticket for exemple) that contains user identifier (username for exemple)

You have to developp your own autenticator component that retrieve this tocken parse it and do work that should be down if user is succefully authenticaed when using your own login page, when done you have to redirect the user to the first requested page
: loading preferences, setting parameters in user session,... 

[deadlockgr]

Actually, my problem is even simpler than this.

My container (WebLogic) takes care of large part of the process you described.

It has an Identity Asserver, the so called SSO Identity Asserter. This picks up the token, and invokes an Authenticator, the OID Authenticator, which actually invokes the Oracle-proprietary LDAP (OID). The authenticator populates the Subject with Principals.

So, when I enter the application the HttpServletRequest has a Subject with Principals (no need for me to invoke the SSO). The way I see it, all I have to do is to transfer this information from the HttpServletRequest to the Identity component, so that I can use Seam Security. The trick is to do it the right way, so that, if the user logs out of the SSO externally and the HttpServletRequest doesn't have a Subject any more, I have to handle the situation by showing an error message, or redirecting to the SSO login page.