Environment:
Oracle 11g database
Weblogic 11.3.6
Webgate 3
Forms&reports 11 g (11.1.2.0)
WebTier 11.1.1.9.0
Problem :
When trying to access form with :
http://localhost:7777/forms/frmservlet
i have this error:
Error 500--Internal Server Error
From RFC 2068 Hypertext Transfer Protocol -- HTTP/1.1:
10.5.1 500 Internal Server Error
The server encountered an unexpected condition which prevented it from fulfilling the request.
but when i set ssoMode = false in formsweb.cfg froms's config file, the forms welcome page displays well.
Any idea?
Thank you.
ssoMode (Single Sign-On parameter) indicates whether the URL is
protected in which case mod_osso, which is Oracle Single Sign-On
Module, will be given control for authentication or continue in the
FormsServlet if not.
It is false by default. It may be set to true in an
application-specific section to enable Single Sign-On for that application.
formsweb.cfg,in which ssoMode parameter may also be overridden , defines parameter values used by the FormsServlet (frmservlet)
The mod_osso component is a module that plugs into Oracle HTTP
Server. It enables the HTTP listener as a partner application that can
use the Single Sign-On server to authenticate users. Once mod_osso is
installed and configured, Web applications can register URLs that
require SSO authentication with the module. Then when URL requests are
received by the HTTP server, mod_osso detects which requests require
SSO authentication and redirects them to the Single Sign-On server.
After the Single Sign-On server authenticates the user, it passes the
user's authenticated identity back to mod_osso in a secure token, or
cookie. The module retrieves the user's identity from the cookie and
propagates the user's identity information to applications running in
the HTTP server instance. The module can propagate the user's identity
information to applications running in the CGI, those running in
Oracle9iAS Containers for J2EE, and it can also authenticate users for
access to static files.
Oracle Forms Services applications can be run in a single sign-on
(SSO) environment using Oracle Login Server (Single Sign-On Server)
and Oracle Internet Directory (OID) to store user name and password
information. For Single Sign-On implementation Oracle Forms is
considered as an 'External Application'.
In Forms, it is possible to obtain the Single Sign-On username via :
GET_APPLICATION_PROPERTY(sso_userid);
This returns a string containing the Single Sign On user ID if the user has been authenticated via the Login Server. A NULL value is returned if SSO was not used.
It is possible to also obtain the user distinguished name (dn) and the subscriber distinguished name (subscriber dn) e.g.
GET_APPLICATION_PROPERTY(sso_usrdn);
GET_APPLICATION_PROPERTY(sso_subdn);
Related
I'm attempting to setup a resource server that hosts resources that require different levels of security.
Through a web application I want to authenticate the users, by specifying the lowest Authentication Context Reference (e.g. basic email/password authentication). This provides an acr value for the session to the resource server. User can then access basic functions of the resource server.
If user wants to access resources of higher security, the resource server should redirect user to authorization server. This redirect should specify a higher ACR.
Within the authorization server, this new value ACR would trigger another authnetication flow including MFA.
The user would then reauthenticate with higher security and therefore obtain access to the requested resource on the resource server that required that higher security.
How can this scenario be achieved?
I do not see anywhere in Spring Security how to easily specify ACR values, or even to trigger re-authnetication of the user.
Checked many many website regarding step-up authentication, adaptive authentication, acr values, etc...
I am trying to understand the purpose(s) of client secrets. Is it to prevent someone from creating a fake server that pretends to be my server? If not, what is it? And does it protect against anything else?
The client secret is used to identify the application that requires an access token in order to access a resource on behalf of the user. Only clients registered in the authentication service can request access. Not only will user authentication be necessary, the client application must also be legitimate. Otherwise someone could impersonate the client application.
This type of client authorization should only be used by confidential clients ([OAuth2 Client Types][2]).
confidential
Clients capable of maintaining the confidentiality of their
credentials (e.g., client implemented on a secure server with
restricted access to the client credentials), or capable of secure
client authentication using other means.
public
Clients incapable of maintaining the confidentiality of their
credentials (e.g., clients executing on the device used by the
resource owner, such as an installed native application or a web
browser-based application), and incapable of secure client
authentication via any other means.
When using flows with clients that cannot guarantee the confidentiality of this secret (i.e. implicit), the identity of the client cannot be verified. In those cases it can be verified by means of the redirection URI. As an additional measure, it should limit the exposure of refresh tokens.
Officially it is no longer recommended to use the implicit flow for security reasons, the recommendation for this type of clients is Authorization Code + PKCE extension. [See OBBA document][1]
For authorizing users within a browser-based application, the best current practice is to
o Use the OAuth 2.0 authorization code flow with the PKCE
extension
o Require the OAuth 2.0 state parameter
o Recommend exact matching of redirect URIs, and require the
hostname of the redirect URI match the hostname of the URL the app
was served from
o Do not return access tokens in the front channel
[1]: https://datatracker.ietf.org/doc/html/draft-parecki-oauth-browser-based-apps-02)
[2]: https://www.rfc-editor.org/rfc/rfc6749#section-2.1
Sometimes you have some ApiResources which called by Clients and there is no any user in the flow. for example fetch instagram's post using instagram's api. now instagram wants to control client behavior so client should be authorized for instagram befor any api call. in this situation you need define some secret for each client to identify them.
This an example of client's secret usage.
I have configured WSO2 Identity Server as IDP and have two applications configured as SP. All working fine, except few things:
when I logged out from one application, another application don't see, that I was logged out
when I login into one application, another application don't see, that I was logged in
IMHO, there is main principles of SSO and SLO.
When I check SecurityContextHolder.getContext().getAuthentication() there is no changes after logout or login in another app.
Maybe I should call WSO2 page /samlsso before every load url?
What can I do wrong? How to retrieve from another app, that user logged out/logged in?
EDIT:
For example, WSO2 API Manager Store have such mechanism:
when I logged out from my application and reload Store page, then going redirection to main not logged page in Store. Same with login.
UPDATE:
I found problem in class org.springframework.security.saml.websso.SingleLogoutProfileImpl. When logout request is coming from WSO2 IS, than objects Authentication and SAMLCredential are nulls and error No user is logged in is occured, but for real user still logged in in Spring SAML application.
Same discussion was here, but with no effect :\
You have to verify whether both apps are calling Identity Server (IS) using the same host name. E.g. https://is.blahblah.com/samlsso.
IS session is based on cookies ('commonAuthId' and 'samlssoTokenId' cookies to be specific). If apps are calling IS using two different host names, there will be two different sessions created at the IS side. For SSO and SLO to happen both apps must share a single IS session.
We are using travelocity.com and avis.com web app for test SAML2 sso. You can found the more details here[1]. Further you can checked this documentation[2] Registering the two service providers in the Identity Server and followed the 1 to 8 steps.
[1] https://docs.wso2.com/display/IS500/Configuring+Single+Sign-On+with+SAML+2.0
[2] https://docs.wso2.com/display/IS500/Customizing+Login+Pages
I have a setup with Tivoli Access Manager (TAM) as reverse proxy for some application servers on the backend side. TAM is responsible for authenticating users. Is it possible to access the credentials a user passed in during TAM authentication in the backend applications?
I need this because the backend applications connect to a Host-System and there the credentials are needed to log in.
there are a couple of options you might have for this :
Since you mention TAM, I guess you are still using 6.X, so you can use a custom CDAS (Cross-domain Authentication Service) library. You would need to implement the library yourself in C and handle the authentication part and return the clear text password as an extended entitlement in the credential. This will allow you to add this extended entitlement as an injected HTTP header for the junctions that require the password. You can get more information here : http://www-01.ibm.com/support/knowledgecenter/SSPREK_6.1.0/com.ibm.itame.doc_6.1/am61_web_devref58.htm%23chap-wsd-write-custom
You can implement your own External Authentication Interface. EAIs are external web applications where WebSEAL can delegate the authentication part. In that EAI, as in CDAS, you would have to handle the authentication part yourself - probably against TAM user registry - and then return the clear text password as an extended attribute in the credential to be used as a custom HTTP header for the junction that requires it. See http://www-01.ibm.com/support/knowledgecenter/SSPREK_6.1.0/com.ibm.itame.doc_6.1/am61_web_devref128.htm%23appx-wsd-eai
Leverage Tivoli Federated Identity Manager and a custom STS chain to do the authentication and return the clear text password as part of the credential.
For all 3 of the above options, you would need to modify the existing backend application to read the injected HTTP header and use the clear text password to perform the actions to the Host.
I have done all 3 for various integrations and I think your best choice is writing an EAI, as CDAS got deprecated with ISAM 7 and the 3rd option requires an additional software component.
Background:
We are building system that required login information for all pages. the application is designed to be Restful application using codeigniter as Phil Sturgeon library.
Scenario:
- username & password is required when a user called any page [Client]
- Authentication is needed where any Api call is fired
I a bit confused how to migrate or do the above scenario, And what are approach to authenticate the application.
A simple way to authenticate users in a RESTful API is using HTTP Basic or Digest Auth. In this setting the user credentials are sent via the Authorization header in a form of username:password as Base64 encoded hash to the server.
As the principles of REST state that the communication between client and server should be stateless, the client has to sent the authorization on every request. In practice this means that you often store the credentials in a session on the client side (as you don't want to the user to enter his credentials on every request). Please note that you should only do this via an secured connection using HTTPS!
To authenticate the application you could use a token based system, such as an API-Key. This means any request would be signed using additional request parameters. If the number of applications is finite and known, you could alternatively simply identify them by their IP.
You could also take a look at OAuth.
Request the login and password for every page is more suitable and more secure(that what I do in my projects), using 'virtual' and stored session in the database may be a second solution but not a good because it will be an additional charge for the DB.