Private:Catalyst Interop 2007 Oracle RP

From OSIS Open Source Identity Systems
Jump to: navigation, search

Oracle(Relying Party)

Last Update: 28 May, 2007


Oracle RP site uses a sample "photo sharing" application called Oracle PhotoShare. This application requires user login using an information card. Initially, when an unauthenticated user acceses the application main page, the user is redirected to the relying party login page. The user will be presented with an opportunity to login using an information card or login using a username and password.

Connection Details

Main URL:
Token Type:
Selector Trigger:HTML
Policy Endpoint:Embedded in HTML
Required Claims:
  1. For Managed Cards:
  2. For Self Issued Cards:
Optional Claims:
  1. For Managed Cards:
  2. For Self Issued Cards:

Issue List

Issue DescriptionFound BySolution Notes
Should there be a common requiredClaims set supported by all IdPs Ramana Turlapati The least common set of required claims that the published RP's have are: ppid and email. However managed cards of certain IdPs (such as STS Live, HumanPresent etc) do not support any of standard claims with the exception of ppid. It appears RP's are forced to handle tokens from STS Live IdP differently from rest of the IdPs
RP security best practices for Token & Claims Validation Ramana Turlapati This issue is related to validation of the token that is posted to RP. The question is what are the set of checks that a RP needs to perform. In other words, what is a minimum set of verifications that a RP needs to perform in order to make the use case provably secure - The following list is an attempt to come up with such a set of recommended practices for RPs.
  1. Check Token Signature Every RP is required to maintain a list of trusted IdPs and respective trust points. When a SAML token associated with a issuer URL is posted to RP, it should be able to perform the signature verification of SAML token and also make sure that the signer is trusted. This will prevent token substitution/tampering/alteration attacks
  2. Check Time Bounds Every RP should check NotOnorBefore/NotAfter attributes as part of validation of SAML and make sure the time window is valid at the time of validation of token. It is assumed that RP's will allow for some time adjustment/sync configuration. This will prevent replay of stale tokens
  3. Check Audience Restriction RP should check if the token is scoped to them, reject if not. This can serve as a first line of defense to thwart rogue RPs that can potentially impersonate users. Every RP is provisioned with a SSL certificate that states the "identity" of RP to card agents. Thereby, card agents can always make the request for the token with the scope of RP's identity and IdPs can issue tokens within the same scope. For all the IdPs/RPs that are participating in the interop, there is not set way this check is being faciliated. In fact, with the exception of STS Live IdP, no oher IdP incorporates <AudienceRestriction> as part of its issued SAML tokens.
  4. Check Claims Claim data needs to validated just like user input especially for self issued tokens
What is right TokenType value? Ramana Turlapati Some IdPs are using "urn:oasis:names:tc:SAML:1.0:assertion" and some use "" and some support both. what is the right value for TokenType?

Planned Features & Status


Notes on public reference


Technical ContactMarketing Contact
Contact Name:Uppili Srinivasan