Login box (embedded in external portals outside IdP)
paw.pogoda at gmail.com
Thu May 8 02:35:25 EDT 2014
Client is forcing this solution because don't want to change current user
experience. In current site there are two places which user could use to
log in (top bar/separate page) and after we create our portal - user
experience should not change he should still log in using the same
(currently existing) components.
if there will be only single place to log in (in current solution) -
separate page, then we'll be able to prepare page which will look similar
at IdP, but the problem is with top bar login which is on all public pages
- we are not able to "simulate" this on IdP side.
2014-05-07 16:05 GMT+02:00 Ian Rifkin <irifkin at brandeis.edu>:
> Client requirement is that login forms should be part of client1/2 sites
>> not IdP domain (only should communicate with IdP to handle authentication).
> In my opinion solution with simple login link/button (here 'client1')
>> would be the best (standard way to handle it), we even try to convince
>> client to it but unfortunately without success.
> You still haven't explained the business case surrounding the requirement,
> other than saying that your client wants it. *Why* do they want it? What
> do they hope will be accomplished by this requirement? Perhaps if you can
> get more details from them regarding their desires/concerns you will be
> better able to guide them to a solution.
> Is it because they care about the URL? Is it because they care about the
> design? Is it because they want have a custom authentication they want to
> use instead?
> host SSO login page on different than IdP domain only to provide user
>> credentials and send this data to IdP authentication engine (to store
>> session cookie)
> It's certainly possible to handle SSO outside of the IdP (as Peter
> mentioned), but I agree with others that it seems odd that have the login
> page in one location and then try to send credentials to the IdP. This is
> why I'm trying to better understand what the rationale is.
> To unsubscribe from this list send an email to
> users-unsubscribe at shibboleth.net
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the users