{5} Accepted, Active Tickets by Owner (Full Description) (39 matches)

Review code for sql, ldap, html injection attacks.

Idle musing: What if there were specific cleaning functions which could be enabled via the options interface to data scrubbing? The I don't force it, and I could allow others to add cleansing functions without changing the core.

Token using namespace not in InclusiveNamespaces? list should result in an error

This includes the following:

1. Support for transport security to secure the transaction on the channel as per ISIP Guide § 5.1.1.1 and WS-SecurityPolicy 1.2 § 8.3
2. Support for message security, specifically a symmetric binding to secure the transaction on the channel as per ISIP Guide § 5.1.1.2 and WS-SecurityPolicy 1.2 § 8.4
3. Support for message security, specifically an asymmetric binding to secure the transaction on the channel as per WS-SecurityPolicy 1.2 § 8.5
4. Support for RP which uses SOAP 1.1
5. Support for RP which uses SOAP 1.2

This includes the following:

1. Requested with “urn:oasis:names:tc:SAML:1.0:assertion”.
2. Returns a SAML 1.1 token when the RP supplies a token type of "http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.1#SAMLV1.1”. Note that SAML 1.0 and SAML 1.1 tokens have the same syntax.
3. Returns a SAML 2.0 token when RP supplies a token type of “urn:oasis:names:tc:SAML:2.0:assertion”.
4. Recognizes equivalence of the multiple URIs for SAML 1.0/1.1 tokens: “urn:oasis:names:tc:SAML:1.0:assertion” and “http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.1#SAMLV1.1”

Specifically, the following error conditions should be handled and return the specified SOAP faults:

1. When the !IdP cannot use the proof key specified in the request, an "InvalidProofKey" SOAP Fault should be returned as per ISIP § 6.2
2. When the card reference used in an Identity Provider transaction is unrecognized or otherwise deemed incorrect by the Identity Provider, a "UnknownInformationCardReference" SOAP Fault is returned as per ISIP § 6.2
3. When the !IdP is unable to publish claim values for all required claims, it may return a "Unable to Satisfy Claims" SOAP Fault as per ISIP § 6.2
4. When a user selects a card with an old card version, the Identity Provider should return a "InformationCardRefreshRequired" SOAP Fault

Cards associated with an account must be expirable. This means we must keep track of an expiration date, among other things, for cards that are associated to accounts.

Administrators and users should be allowed to delete an information card/account association

Are there other jspolicy scripts that the JNDI context provider needs to allow an administrator to configure.

Overhaul the look and feel - buttons, images, background images, etc. - so the whole thing - both user and admin experience looks more smooth and professional.

Do we need an instance of ATS in OTIS? The current use cases seem to not require it.

Currently clients can't specify what content types they support, we need to support content types as a first step to different formats, atom, opensocial, xml, xdi, json etc.

Reduce the chance to misuse LDAP Test Server in production environment.

We need to resolve various issues raised in our 7/18/2008 Sprint review, see #701. Need to articulate what is our Authorization Control Model. Do we need to allow administrators to limit which attributes are queried?

Include:

• Links to IdAS model
• Additional documentation

Provide an interface manager that will allow a developer / sysadmin to create mappings between specified Bandit attributes and configured Identity stores