authschemes and portal / iviews - need help

[tim_alsop]

I am aware that when I logon to the SAP portal, normally due to authschemes.xml configuration the default authscheme is used to authenticate the user (which uses the ticket auth template). I am interested to know if it is possible to configure the portal so that by entering a different url, I can use a new iview, and the iview will specify a non-default authscheme. This would allow me to logon using one method by entering the normal portal login URL and by another auth method by entering a different URL.

From what I understand about iviews (not much) I think this is possible, but I don't know for sure, and how to make it work. Can you help ?

Regards,

Tim

[dhorions]

I can't really answer your question, because I don't know the answer.

But your question made me think of a weblog that was posted last week :

<a href="/people/abdulbasit.gulsen/blog/2007/03/13/add-fancy-logon-iview-into-anonymous-portal">Add Fancy Logon Iview Into Anonymous Portal</a>.

Maybe you can find something there, or ask the author.

[tim_alsop]

I don't think adding an anonymous login screen as this URL/blog describes actually helps me much, but I appreciate the suggestion.

The initial problem I have, is understanding how portal logon works. It looks like the initial logon to the portal is controlled via the "default" authscheme reference, as defined in authschemes.xml file. This refers to the ticket auth template. Once logged into the portal, if I access content which is configured (via an iview) to use an authscheme other than default, and if the authscheme priority is higher than the priority of the default authscheme, then I will be asked to authenticate using the login screen/method from the iview configured authscheme and the new sso2 ticket issued will then replace the sso2 ticket which is already in my browser from the initial portal login. Is this understanding correct ? If not, can somebody please correct me ?

Assuming that the above is correct, then I want to know if there is a way to configure initial logon to the portal to use a different iview (and hence an authscheme), depending on which URL is used to access the portal. e.g. Does initial portal login use an iview, which I can change in portal content administration to refer to a different authscheme, instead of it using default ?

Regards,

Tim

[yonko_yonchev]

Hi Tim,

As I understand your purpose is to logon users with a different authentication method based on the URL. If this is correct, then you don't need to change the logon form (that's what the iView shows - there isn't a logon iView AFAIK).

Instead, you can go in the the Master Rule Collection, direct the logon to a custom Portal Desktop and in that custom Portal Desktop set the relevant iView authentication schemes to what you need.

Details on how to do this here:

http://help.sap.com/saphelp_nw2004s/helpdata/en/4b/29cf122f414721964269e1b675d62c/frameset.htm

Do hope this helps you out.

Regards,

Yonko

[tim_alsop]

Yonko,

This looks good. I will try it out and see if it does meet our needs, and then let you now and award points if appropriate

Take care,

Tim

[tim_alsop]

Yonko,

Now I have read the sap help page you referred to, and given this some more thought I am not sure it is what we need :-(. Or maybe I misunderstood what you were suggesting ? It appears that creating custom portal desktops will change what a user sees depending on who they have authenticated as. The problem I see with this, is that the authentication needs to be performed before the portal can determine what custom desktop to display. I cannot see how changing the iview authscheme in a custom desktop will meet my needs.

Perhaps if I give an example it will help understanding ... Lets suppose Integrated Windows Auth is setup for default authentication when logging onto portal. Then, somebody wants to logon to the portal using a userid+password (e.g. using basicpasswordloginmodule). To do this we need some way to refer to a different URL for portal login, so that the initial portal authentication is done using the basicpasswordloginmodule instead of the integrated windows authentication which will be configured as the default. I know we can do this using a servlet which authenticates the user using a specific authscheme, and then redirects to portal home page after sso2 ticket has been issued, but I am exploriing other possibilities as well.

Cheers,

Tim

[yonko_yonchev]

Hi Tim,

The Master Rule Collection can also filter by URL alias (comes after the URL path). My idea was to use this to provide different desktops, with different authentication schemes for the iViews within those portal desktops. Users will then access their content from a URL that includes the alias.

If you only want to use this for SPNego (I assume this is what you refer to by Intergrated Windows Authentication), then you can try <u><b>not</b></u> register as SPN the URL for basic authentication, put the logon module for Basic Authentication in the Ticket logon stack and set the JAAS login module flags appropriately. There was another thread on this approach.

I would still suggest the Master Rule Collection, though.

Regards,

Yonko

[tim_alsop]

Jonko,

I was under the impression from what I read on SAP help library, that since it is possible to check the URL alias and it is also possible to configure a rule based on the authenticated user, that the URL alias will only be checked after the user has authenticated to the portal. Have you implemented/tested what you have suggested in order to be sure it works as you suggest ?

Yes, I am aware of the other thread related to this concept which somebody asked a few months ago. As I said, we are considering all the options available, including the servlet redirection approach, and also the approach with the SPN and coding BasicPasswordLoginModule as a fallback in the ticket auth template.

If what you are suggesting works, then there might now be 3 solutions to consider instead of 2 ?

Regards,

Tim

[Former Member]

Hi Tim,

how about replacing the portal logon page by a redirect to your own jsp/servlet ? In this case, you can create a logon stack depending on additional data and you may in addition also prepend the logon page asking other questions.

Regards,

Patrick

[tim_alsop]

Patrick,

We are already looking into this option, but we are having difficulty calling the UME factory to force authentication with a particular authtype. The UME factory API we are using at the moment to trigger authentication does not support the authtype as a parameter. Can you suggest a function we need to call in our serlvet to cause UME to authenticate the user using a specific authtype ?

Thanks,

Tim

[Former Member]

Hi Tim,

authschemes are only supposed to work with portal applications.

In the case I mentioned, you would deploy one application per authentication stack. This would give the same result at least as far as I do understand your issue.

regards,

Patrick

[yonko_yonchev]

Hi Tim,

this is a deeply custom solution, so no I can't say I tested this. You may also have to use a combination of anonymous logon and iViews that require authentication.

The advantage of Master Rule Collection is that it can also work with other authentication mechanisms, not just with SPNego. If your use case is limited to SPNego, then the unregistered SPN or adding a JSP application as Patrick suggests will do the job for you IMHO.

Regards,

Yonko

[tim_alsop]

Patrick,

Sorry, but I am now very confused. I was under the impression that authschemes were configured in authschemes.xml and available for use in any J2EE authentication requirement, not just for portals. I have seen references before to using authschemes for non-portal login, and can see nothing which is portal specific.

My understanding of what you said before is :

1. user accesses portal

2. portal login page redirects to our servlet, which may ask the user some questions or give them options before deciding what type of authentication to use.

3. our servlet triggers the authentication via UME API

4. The auth stack is processed based on the authscheme name given in UME API, and CreateTicketLoginModule will be used to issue an SSO2 ticket for SSO purposes.

5. The servlet will then redirect back to the portal page and the SSO2 ticket in browser will allow the logon to complete.

Is the above what you were suggesting, or if not, can you help me understand where I am getting this confused/wrong ?

The part we are having problems with is step 3 where we are unable to pass the authscheme we want to use as a parameter.

Thanks,

Tim

[Former Member]

Hi Tim,

what I said was:

1. user accesses portal

2. portal login page redirects to our servlet, which may ask the user some questions or give them options before deciding what type of authentication to use.

3. our servlet triggers the authentication via UME API by calling an application with the appropriate login stack configuration

4. The auth stack is processed based on the <b>login stack configuration of this application</b> and CreateTicketLoginModule will be used to issue an SSO2 ticket for SSO purposes.

5. The servlet will then redirect back to the portal page and the SSO2 ticket in browser will allow the logon to complete.

you will have to deploy one application per login stack configuration.

regards, Patrick

[tim_alsop]

Yonko,

As you may know, we are an ISV, and some of our customers are sharing their requirements with me so I am trying to explore the options for us to enhance our existing products to meet their needs. These customer are asking about using the portal, but there are other cases where non-portal apps need a combination of integrated authentication and some other authentication method (also provided by a login module we provide or a SAP supplied login module).

I would therefore rather solve the problem in a way that will work well with the portal, and not require any complex changes to portal configuration, but also have potential to work with non-portal web accessible applications (e.g. bsp apps, or any integrated ITS app). When our code is used to access an app in integrated ITS (configured in SICF t-code) we redirect to our servlet in order to trigger the authentication via the UME factory API. If wen extend this existing servlet to include authscheme=<scheme-name> then we can provide a very flexible solution which can be used with the portal and also with ICF apps. However, as I have said to Patrick we are having difficulty coding this using the UME API functions.

Thanks,

Tim

[tim_alsop]

Patrick,

Regarding "you will have to deploy one application per login stack configuration.". Which application are you referring to ? Can you refer me to a code example of where the UME API function is used in this way to call an application "with the appropriate login stack configuration" ?

If above is correct, then I assume that "the application" is something that would be configured via Visual Admin Security Provider with a specific stack just like there are apps already deployed called sap.com/BonusCalculation..., sap.com/EducationData... etc. ?

I think I am getting closer to understanding. Thankyou for your help so far.

Thanks,

Tim

[Former Member]

Hi Tim,

I was talking about a J2EE application. For details about the J2EE standard and applications, please have a look at the docs from Sun.

Calling an (other) application means telling the browser to access the system at the URL of this application. you usually configure the appication base URL in the web.xml. This is not an UME function at all.

Each application can have it's own login stack on our J2EE server which is configured using the security provider service as mentioned by you.

Regards,

Patrick

[tim_alsop]

Patrick,

Thankyou. I think I understand now. We will do some tests soon and let you know if we have any more questions. Then we can close this thread and award points.

I appreciate your help.

Regards,

Tim

[tim_alsop]

I have awarded points. Thankyou to everybody that contributed.